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INTRODUCTION 

This  paper  is  part  of  a  larger  study  examining  the  question  of  whether 
or  not  companies  are  choosing  to  manage  a  complex  engineering  activity 
such  as  large-scale  software  development  with  a  range  of  strategic 
consideration?  and  organizational  as  well  as  technological  approaches  that 
corresponds  to  the  spectrum  usually  associated  with  "hard"  manufacturing, 
i.e.  job  shops,  batch  organizations,  and  factories  exhibiting  various  degrees 
of  flexibility  in  product  mixes  and  technologies.  The  research  project 
includes  the  proposal  of  technology  and  policy  criteria  defining  what  a 
factory  environment  for  software  might  look  like;  a  survey  of  38  software 
facllties  in  tha  U.S.  and  Japan  to  determine  where  firms  stand  in  relation  to 
these  criteria;  and  detailed  case  studies  examining  the  technology  and  policy 
Implementation  process  followed  at  firms  identified  as  being  close  to  the 
factory  model .  * 


There  are  several  interrelated  conclusions:  (1)  This  spectrum,  including 
"factory"  approaches,  is  observable  in  a  statistically  significant  sample  of  38 
software  facilities  in  the  U.S.  and  Japan.  (2)  There  appears  to  be  nothing 
inherent  in  software  as  a  technology  that  prevents  some  firms  from 
managing  the  development  process  more  effectively  than  others.  (3)  The 
approach  to  developing  a  technological  infrastructure  to  aid  software 
development  is  not  significantly  different  between  Japanese  and  U.S.  firms. 
(4)  But,  Japanese  firms  --  led  by  the  NEC  group  and  Toshiba,  and  followed 
by  Hitachi  and  Fujitsu  --  are  significantly  ahead  of  most  U.S.  competitors  in 
applying  a  disciplined  and  flexible  "factory"  approach  --  production- 
management  concepts,  general-use  tools,  standardized  procdures,  effective 
quality-control  techniques  --  to  large-scale  software  development.  Other 
U.S.  firms  relatively  close  to  the  flexible  factory  model  are  TRW  and,  to  a 
lesser  extent,  Sperry  and  System  Development  Corporation  (SDC),  now  both 
part  of   Unisys. 

This  particular  paper  is  on  System  Development  Corporation,  formerly  a 
Rand  Corporation  and  then  a  Burroughs  subsidiary  that  attempted  the  first 
U.S.  "software  factory"  experiment  in  the  mid-197ns.  It  is  an  important 
case,  for  two  main  reasons:  One  is  that  SDC's  Software  Factory  is  part  of 
a  larger  attempt  in  the  U.S.  and  other  countries,  beginning  in  the  late  1960s 
and  early  1970s,  to  reflect  on  various  programming  experiences  and  suggest 
how  an  organization  might  bring  together  new  tools,  methods,  and  procedures 
to  improve  the  performance  of  software  engineers.  Analyses  of  IBM's 
development  of  the  operating  system  for  the  360  family  of  mainframes,  as 
well     as     numerous     other    government     and     private-industry     projects,     were 


particularly  important  contributors  to  an  emerging  body  of  literature  on 
software  engineering.  Two  reports  on  the  SDC  Software  Factory  published 
in  1975  and  1977  were  a  part  of  this  literature  and  presented  the  first  well- 
publicized  attempt  to  think  of  a  factory,  rather  than  a  laboratory,  as  a 
model  for  software  development.  Second,  through  its  publications,  SDC 
influenced  the  strategies  and  practices  of  several  Japanese  firms  that  have 
more  aggressively  promoted,  explicitly  or  implicitly,  highly  disciplined 
approaches  to  software  engineering;  these  firms  include  Hitachi,  Toshiba,  and 
NEC. 

The  ideas  and  practices  that  came  out  of  the  SDC  experiment  also 
provided  the  basic  model  for  the  criteria  used  to  define  a  software  factory 
in  the  survey  described  above.  The  survey  reveals  that,  while  SDC  managers 
did  not  consider  their  factory  experiment  to  have  been  a  total  success, 
Unisys/SDC  ranked  11th  among  38  facilities  responding,  and  3rd  among  U.S. 
facilities,  behind  only  TRW  and  Unisys/Sperry  (see  Appendix  tables).  Thus, 
the  company  has  been  more  successful  or  determined  than  most  other  U.S. 
firms   in   "rationalizing"   its  software-development  process. 

This  paper  is  organized  as  follows:  The  first  two  sections  discuss  the 
background  to  the  Software  Factory  experiment  and  SDC's  evolution  as  a 
company  and  areas  of  business.  The  third  section  analyzes  the  components 
of  the  Software  Factory,  which  can  be  broken  down  into  a  policy 
infrastructure,  embodied  in  SDC's  Software  Development  Manual,  and  a 
technological  infrastructure,  which  took  the  form  of  SDC's  Factory  Support 
System.        Section     IV    compares    the    performance    of    the    Factory    in    operation 


with  the  five  major  problems  it  was  designed  to  solve;  these  were  concerned 
with  project  management  and  control,  tool  availability,  and  reusability  of 
program  components  (code).  The  next  section  discusses  two  problem  areas 
that  the  Factory  created,  relating  to  an  insufficient  "work  flow"  and 
conflicting  responsibilities  among  managers,  and  the  final  solution  SDC 
arrived  at:  maintain  the  factory  procedures  and  some  of  the  tools,  but 
decentralize  the  factory  workers. 

The  main  conclusions  of  this  study  are  that  the  experiment  did  not 
succeed  as  expected  because  SDC  attempted  to  impose  a  sophisticated 
technological  and  policy  infrastructure  on  both  mananagers  and  engineers 
without  adequate  analysis  or  anticipation  of  the  work  flow  and  the  reactions 
of  its  personnel,  especially  in  middle  management.  On  the  other  hand,  data 
from  the  survey  and  comparisons  with  other  firms,  especially  in  Japan, 
suggest  that  the  factory  model  for  software  is  not  inherently  impossible  to 
implement. 


I.    SDC  AND  THE    "SOFTWARE  FACTORY"   EXPERIMENT 
The  Company 

System  Development  Corporation  (SDC),  first  under  the  Rand 
Corporation  and  then  Burroughs  and  now  Unisys,  has  served  as  a  strategic 
business  unit  primary  responsible  for  doing  software  development  and  systems 
engineering  for  the  United  States  Government.  With  facilities  across  the 
U.S.    and   approximately  6,000  employees   in    1987,    it  was  a  major  U.S.    provider 


of  software,  hardware,  and  system  integration  for  applications  focusing  on 
airspace  management;  command,  control  and  intelligence  systems;  custom 
workstations;  and  networks.*^  According  to  the  Director  of  Software 
Engineering  in  SDC's  Systems  Group,  Ronald  Atchley,  SDC  applications 
software  programs  are  "usually  real-time  systems  [for]  command  and  control... 
on  various  pieces  of  equipment  --  DEC,  Gould,  minis,  PC's,  Burroughs,  IBM 
mainframes,  Amdahl,  Univac  1100."  Much  of  this  work  has  been  for  the  U.S. 
Department  of  Defense  --  "any  large  scale  system  that  they  would  like  to 
have  built  and  we  would  like  to  build  for  them.  .  .  .  They're  all  primarily  large 
scale  systems  where  we  can  leverage  our  software  development  skills  to  get 
the  bigger  jobs. " 

SDC  has  been  a  key  defense  contractor  ever  since  the  launching  in  the 
early  1950s  of  the  SAGE  (Semi-Automatic  Ground  Environment)  air  defense 
system  program,  the  first  large  scale  real-time  system  ever  built.  According 
to  Atchley,  SAGE  "was  the  beginning  of  SDC."  The  Air  Force  gave  the 
contract  to  Rand  Corporation,  which  in  turn  spun  off  their  System 
Development  Group  as  the  System  Development  Corporation.  SAGE  thus 
became  "the  very  first  system  ever  built  [by  SDC];  it  was  the  first  air 
defense  system  ever  built,  the  first  large  scale  computer  system  built,  and  it 
was  the  first  system  with  consoles,  and  light  pens  and  displays  and  all  this 
other    stuff,"     recalled    Atchley.^  Other    recent    SDC    jobs    illustrate    the 

company's  work  requirements  and  resources:  a  new  air  traffic  control 
transponder  and  data  link  for  the  Federal  Aviation  Administration  (FAA);  a 
fault  tolerant  computer  system  for  this  application  in  a  joint  venture  with 
Westinghouse;   an  automated  search   system  for  the  U.S.    Patent  and  Trademark 


Office;  a  Medicaid  Management  Information  System  for  Massachusetts;  and  an 
Emergency  Command  and  Control  System  (ECCS)  for  the  Los  Angeles  Police 
Department. 


The  Experiment 

Initially,  it  seems  that  the  factory  idea  emerged  out  of  SDC's 
organizational  structure  for  major  development  projects,  instituted  for  SAGE 
and  unchanged  even  in  1987.  Managers  led  by  Jack  Munson  (now  manager  of 
the  Houston  facility)  thought  it  was  possible  to  incorporate  factory  notions 
of  division  of  labor  and  work  flowing  through  lines  in  a  centralized  facility, 
as   Atchley   recalled: 


We  implemented  it  with  the  idea  that  we  would  have  three 
separate  groups  of  people.  We  would  have  the  requirements 
analysts,  designers,  or  what  now  is  possibly  called  system 
engineering.  We  would  have  the  program  production,  which  is  now 
software  engineering.  And  we  would  have  the  test  and  evaluation. 
Those  three  would  be  disciplines  whereby  the  work  would  be  done, 
and  the  work  would  flow  through  the  factory.  ...  In  the  SAGE 
environment  we  had  a  group  called  Requirements  Design  Branch, 
and  they  did  the  specification.  We  had  the  Programming 
Development  Branch,  and  we  did  the  coding  and  the  preliminary 
testing;  and  we  had  the  System  Test  Group  in  Phoenix  which  did 
the  final  testing.  So  we  just  kind  of  moved  that  concept  into 
place  and   made   it  more  formal. 


The  first  public  mention  of  the  experiment  seems  to  have  come  in  May 
1975,  when  two  SDC  managers,  Harvey  Bratman  and  Terry  Court,  published 
an     article     in     IEEE     Computer,     titled     "The     Software     Factory."^  This 

described     an     experimental     facility     with     about     200    programmers     in     Santa 
Monica,    California.       The    procedures    and    tools    under    development    were    "not 


new  or  revolutionary"  but,  when  integrated  and  consistently  applied,  the 
authors  believed  they  had  the  potential  to  radically  change  the  way  large- 
scale  applications  software  was  being  developed.  Bratman  and  Court 
explained  their  project  in   highly  optimistic  terms: 


The  Software  Factory  is  an  integrated  set  of  standards,  procedures,  and 
tools  that  supports  a  disciplined  and  repeatable  approach  to  software 
development  [through]  the  concepts  of  structured  programming,  top- 
down  program  development,  and  program  production  libraries,  and 
incorporates  hierarchically  structured  program  modules  as  the  basic  unit 
of  production.  ...  [It]  replaces  ad  hoc  conglomerations  of  developmental 
techniques  and  tools  with  standard  engineering  techniques.  ...  In  brief, 
the  Software  Factory  is  an  excellent  vehicle  for  the  configuration 
control  of  a   system  during  operational   and  maintenance  stages.^ 


There  seemed  little  doubt  that  programs  with  hundreds  of  thousands  of 
lines  of  code  would  benefit  from  better  systems  to  facilitate  the  division  of 
labor  and  improve,  in  this  and  other  ways,  the  performance  of  engineers  and 
other  programmers.  But  the  poor  correlation  between  program  productivity 
and  experience  frustrated  the  SDC  managers  and  suggested  to  them  "the  lack 
of  a  methodological  and  well  founded  body  of  knowledge  on  the  software 
development  process."'  With  regard  to  the  tools  and  programming  concepts 
available  to  deal  with  problems  in  software  production,  the  authors 
complained  that,  "they  are  either  not  used  at  all  in  system  development  or, 
when  they  are  used,  they  are  not  used  in  an  integrated  manner,  but  are  put 
together  ad  hoc  each  time  a  large  system  programming  project  is  begun." 
To  change  this  situation,  Bratman  and  Court  advocated  a  methodology  that 
emphasized  "discipline  and  repeatability."  And  they  proposed  "to  apply  it 
consistently  and  to  support  it  with  tools  that  will  simplify  and  standardize 
its  application.""        In  one  bold   stroke,    SDC  thus  attempted  to  institutionalize 


good  tools  and  practices  to  solve  the  basic  problems  managers  had  encounted 
in  software  development.  Bratman  and  Court  placed  these  into  five 
categories : 


1)  Lack  of  Discipline  and  Repeatability:  Bratman  and  Court  referred  to 
the  absence  of  "standardized  approaches  to  the  development  process. 
Each  time  a  software  system  is  developed,  the  process  is  partially 
reinvented,  with  the  consequence  that  we  never  become  very  proficient 
at  this  process,  nor  are  we  able  to  accurately  predict  the  time  and 
resources    required." 

2)  Lack  of  Development  Visibility:  They  complained  that  code  production 
was  often  used  to  indicate  progress  in  completing  a  software  project, 
but  this  did  not  measure  "completeness  of  performance  requirements, 
the  design  itself,  or  how  well  the  code  implements  the  design."  Not 
until  system  testing  did  it  become  clear  how  well  a  project  was 
progressing;  and  fixing  problems  at  this  stage  "is  exceedingly  expensive 
and  time  consuming...  Managers  have  difficulty  in  tracking  the 
progression  of  the  system  from  phase  to  phase,  and  as  a  result  they 
have  problems   in   planning  and  controlling  the  developing   system." 

3)  Changing  Performance  Requirements:  The  problem  here  was  that 
"Performance  requirements  are  subjected  to  interpretation  and  change 
as  soon  as  the  system  design  and  implementation  process  begin  the 
translation  of  requirements  to  computer  programs."  Not  only  was  it 
nearly  impossible  to  completely  specify  performance  requirements  before 
detailed  design  and  coding,  but  there  were  often  disagreements  on  the 
meaning  of  certain  requirements,  changes  demanded  by  the  customer, 
and  the  like. 

4)  Lack  of  Design  and  Verification  Tools:  Several  tools  --  such  as  high- 
level  languages,  data-management  systems,  subroutine  libraries,  and 
debugging  tools,  facilitated  coding  and  debugging.  But  Bratman  and 
Court  asserted  that  these  activies  accounted  for  only  about  20%  of 
development  costs.  "There  are  few  widely  used  tools  and  techniques 
which  provide  significant  support  to  other  components  of  the 
development  process  such  as  requirement  and  design  specification, 
verification  and  validation,  project  management  and  control, 
documentation ,    etc .  " 

5)  Lack  of  Software  Reusability:  There  were  many  application  areas  that 
required  similar  logic,  but  there  was  little  capability  to  reuse  software 
components.  "Extensive  use  of  off-the-shelf  software  modules  would 
significantly  lessen  the  risk  and  shorten  the  time  required  for  software 
development.  "^ 
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The  problem  with  the  factory  strategy  was  sustained  implementation. 
Due,  apparently,  to  the  objections  of  managers  and  programmers,  as  well  as 
to  some  technical  obstacles,  SDC  was  unable  to  carry  its  factory  beyond  the 
prototype    stage. '^  According    to    one    of    the    managers    involved    in    the 

experiment,  David  Deaver,  to  get  software  engineers  to  follow  the  factory 
concept,  it  was  necessary  either  to  "force"  employees  to  follow  the  required 
procedures,  or  develop  better  tools  to  facilitate  reusablity  and  the 
interconnecting  of  modules,  and  then  encourage  their  use.  It  thus  appeared 
to  Deaver  that  the  software  factory  was  simply  another  one  of  those  ideas 
that  was  valuable  and  exciting  but  "ahead  of  its  time."'' 

SDC  retained  many  of  the  procedures  it  developed  for  the  factory  but 
decided  to  decentralize  --  divide  programmers  into  different  functions  and 
areas  corresponding  to  customer  markets.  The  word  "factory"  was  also 
abandoned  at  SDC  and  seems  to  have  become  an  anathema  to  both  managers 
and  programmers.''^  Among  other  American  companies  during  the  1980s, 
despite  the  existence  of  several  experiments  applying  computer-aided  tools  to 
large-scale  programming  projects,  none  claimed  to  have  built  and  maintained 
a  "factory"  for  software  production .  ^"^  On  the  other  hand,  several  Japanese 
firms  adopted  the  factory  model  for  software  and  implemented  it  with 
considerably  more  enthusiasm,  combining  flexibility  in  product  design  with 
remarkable  improvements  in  engineering  productivity  and  quality  control.'^ 
But  at  SDC,  a  pioneer  in  the  very  concept  of  the  software  factory,  many 
questions  remain:  Did  the  Factory  accomplish  what  it  set  out  to  do?  Or 
was  there  something  with  the  technological  or  managerial  components  of  the 
Factory,    or  the  basic   philosophy   behind  this   approach   for  this   company?      In 


short,    what  went   right  and  what  went  wrong,    and  why? 


II.    FACTORY  COMPONENTS:      POLICIES  AND  TECHNOLOGIES 

SDC's  Santa  Monica,  California  facility  attempted  the  Software  Factory. 
Atchley,  who  joined  the  project  toward  its  end  in  1977,  recalled  "That's  the 
only  large  open  office  we  had  at  that  time.  We  were  in  a  building  about  a 
block  long,  two  stories  high,  three  long  corridors  with  cross  corridors  and 
patios  in  the  center.  Everyone  had  an  outside  window.  That  building  still 
stands,    but  we've  moved  out.  " 

Bratman  and  Court  viewed  the  Factory  as  a  vehicle  for  developing 
software  systems  of  any  size,  complexity,  application,  object  computer,  or 
programming  language.  The  basic  strategy  was  to  establish  a  standardized 
methodology  that  would  make  software  production  a  'disciplined,  repeatable 
process  terminating  in  specified  results  within  budgeted  costs  and  on  a 
predefined  schedule.  '  Their  goal  was  to  eliminate  or  reduce  the  need  to 
retool  the  facility  for  each  new  system,  thereby  allowing  the  organization  to 
get  projects  underway  quickly  and  improve,  through  capturing  the  benefits  of 
experience,  aspects  such  as  program  design,  code  production  methodology, 
and  project  management.  Bratman  and  Court  did  not,  therefore,  envision  the 
Software  Factory  as  simply  a  building  housing  a  collection  of  tools.  They 
maintained  that  the  success  of  a  software  development  effort  depended  upon 
the  consistent  use  of  good  techniques  and  practices,  in  both  technical  and 
management  areas;  and  on  standardization,  faithfully  established  and 
maintained  to   reflect  changing  conditions   and  continual   improvement.^ 
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Two  "basic  structural  and  control  components"  comprised  the  Factory: 
(1)  standards,  procedures,  and  organizational  principles,  embodied  in  the 
Software  Development  Manual,  to  provide  consistency  in  approach;  and  (2)  an 
integrated  set  of  standard  tools  (the  Factory  Support  System)  to  increase  the 
efficiency  and  effectiveness  of  the  software  development  process.  The 
Factory  Support  System  automated  many  of  the  manual  procedures,  and 
provided  the  total  system  development  framework,  a  dynamic  management 
data  base,  and  tools  to  help  assure  cost  and  schedule  integrity.  As  Bratman 
and  Court  explained,  their  methodology  was  consistent  with  government 
contract  requirements  but  was  to  stand  on  its  own  as  part  of  the  Factory 
system: 


In  general,  the  standards  and  procedures  are  computer- 
independent  and  application-independent  and  have  been 
developed  as  the  foundation  and  basis  for  the  Software 
Factory.  In  addition,  they  are  compatible  with  US  military 
standards,  US  Air  Force  Manual  375  requirements,  and  the 
better  commercial  practices.  Standards  such  as  the  US  Air 
Force  System  Command  Manual  375  series  developed  by  The 
Electronic  Systems  Division,  the  Military  Standard 
380/480/483  series  developed  for  DoD,  and  similar  procedures 
developed  by  the  US  Army,  the  Navy,  and  by  the  Joint 
Technical  Support  Activity  for  The  World-Wide  Military 
Command  Control  System  Advanced  Data  Processing 
Equipment  were  reviewed  and  incorporated  where  practical. 
However,  where  the  emphasis  in  these  efforts  was  on 
product  descriptions.  System  Development  Corporation  has 
expanded  this  to  include  detailed  process  descriptions, 
including  both  methods  and  procedures. 


Software  Development  Manual   (SDM) 

SDC     produced     the    Software    Development    Manual    to    formalize    this 
philosophy   and   methodology.       In    1987  this   was   still    used   at   SDC   facilities   in 
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Santa  Monica  and  Camarillo  (California),  Paoli  (Pennsylvania),  and  McLean 
(Virginia),  a  decade  after  the  Factory  experiment,  although  it  was  in  the 
process  of  being  replaced  by  a  Department  of  Defense  Military  Standard 
(2167): 


The  SDM  describes  a  set  of  standards  and  procedures  for 
the  development  of  a  software  system  from  both  tiftie-phased 
and  functional  organization  points  of  view.  It  recognizes 
the  close  interralationship  between  software  development 
tasks  and  the  functional  skills  necessary  to  do  the  job.  The 
SDM  is  organized  in  sections  which  follow  the  phases  of  a 
project  throughout  its  entire  software  development  life 
cycle.  Each  section  provides  detailed  standards  and  defines 
the  objectives,  the  initiation  and  inputs,  termination  and 
outputs,  applicable  reviews,  and  activities  to  be  performed 
for  each  phase  prior  to  initiation  of  the  next.  .  .  .  The  SEM( 
also  defines  and  provides  guidance  for  those  functions  that 
are  not  unique  to  a  specific  phase  but  are  applicable 
throughout  the  entire  project  life  cycle.  These  functions 
are: 

-  project  management 

-  configuration   management 

-  quality   assurance 

-  contracts   administration 

-  program  control 

Although  the  relative  emphasis  on  these  functions  varies 
with  each  phase  of  the  software  development  life  cycle, 
they  normally  all  operate  to  some  degree  throughout  a 
project.  The  SDM  defines  each  function,  outlines  its 
purpose  and  goals,  provides  cautions  concerning  critical 
areas  of  applications,  lists  inputs  and  outputs,  specifies 
mandatory  requirements,  and  provides  examples  of 
applications  as  well  as  recommending  organizational 
principles  for  control. 


The  SDM  outlined  the  tasks  to  be  performed  at  successively  more 
detailed  levels  of  each  phase  of  the  development  life  cycle,  discussing  the 
objectives  and  major  activities  involved.  Recognized  techniques  and 
concepts,     such    as    structured    programming,    top-down    program    development, 
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and  program  production  libraries  were  incorporated  throughout  the  discussion 
of  each  development  phase.  Overall,  the  SDM  was  designed  to  describe  how 
a  standardized  methodology  and  available  Factory  tools  would  work  together 
to  provide  a  step-wise  refinement  approach  to  software  development. 

Factory  Support  System 

The  Factory  Support  System  was  the  name  given  to  an  "integrated  and 
extensible  facility  of  software  development  tools  that  supported  the 
recommended  methodology."      It  provided  these  features: 

-  supported  top-down  development 

-  automated  management  support 

-  maintained   requirements  through   implementation 

-  provided   library/history  capability 
possessed  complete  symbolic  system  data  control 

capability 

-  assisted  automated  program  checkout 


The    Factory   Support   System    ran   on    a   host  machine    (IBM  370,    initially) 

and   used  the  facilities  of  the  host  operating   system.      The  design  was  flexible 

in   the  sense  that   it  allowed   new  tools   to   be  added   as   they   became  available. 

Atchley   admitted   that,    in    1975-1977,    the  tools   were   not   all   there;    some  were 

under   development    at   the   time    Bratman    and    Court    published    their   articles, 

and  others   never  materialized:      "We  still  don't  have  a  good  editor.    ...   We  had 

to   do   the   traceability    [matrix]    by    hand..."       Bratman    and    Court   also   noted 

that    the    technical    infrastructure   of    the    Factory    was    still    evolving    in    1975- 

1977,    although    they    were    highly    optimistic    about    their    ability    to    completed 

an   "automated"  facility: 

Our  long  term  plan  is  that  the  Software  Factory  will  be 
augumented  by  the  continued  development  of  more 
sophisticated    tools     and    techniques     such     as     application- 

13 


oriented  process  design  languages,  reusability  technology, 
correctness  verifiers,  and  cross  compilers,  and  will  therefore 
evolve  into  a   truly   automated   software  development  facility. 

The    "basic    structural    and    control    components"    of   the   Software    Factory, 

as    Bratman   and   Court  described   them,    included   three  main    sub-systems: 

Factory  Access  and  Control  Executive  (FACE):  performed 
control  and  status  gathering  services  for  all  processors, 
supported  the  factory  command  language,  integrated  the 
processors  with  the  system  development  data  base,  and 
provided   program   production   library    (PPL)    services. 

Integrated  Management,  Project  Analysis,  and  Control 
Techniques  (IMPACT):  utilized  production  data  base 
information  on  milestones,  tasks,  resources,  system 
components,  and  their  relationships  to  provide  schedule, 
resource  computation,  and  status  reports  at  the  individual 
components  level  or  summarized  at  any  module  or  task 
hierarchy   level. 

Project  Development  Data  Base:  a  data  base  established  for 
each  project  using  the  facility  and  containing  all  the 
schedules,  tasks,  specification  components,  test  cases,  and 
their  relationships  along  with  the  various  forms  of  the 
evolving  software  components  and  the  complete  development 
status.  This  actually  consisted  of  two  parts:  a  software 
development  data  base  and  a   project  control  data  base. 
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In  general,  the  project  development  data  base  facilitated  the  automation 
of  program  development,  management  visibility,  configuration  control,  and 
documentation.  The  software  development  data  base  extended  the  program 
production  library  concept;  this  kept  copies  of  program  modules  from  their 
first  functional  definition  through  their  completion  as  object-language 
programs.  The  project  control  data  base  maintained  the  system  and  program 
descriptions  and  supporting  management  data,  which  was  oriented  toward  the 
software  system  structure  and  the  activities  performed  to  develop  the 
software  system. 

IMPACT    was    particularly    central    to    the    management    of    the    Factory. 

This    assisted    the   manager   of   a    software    project    in    planning    and   monitoring 

the    production    of    various    items,     such    as    specification    documents,    program 

modules,    user  manuals,    etc.    for  which   his   project  was   responsible.      "It  helps 

him    plan,    monitor,    and    control    the    work;    define    and    control    the    software 

configuration;    and   ensure  the  observance  of  quality   assurance  measures.       It 

assists    him    in    the    preparation    of    management    reports,    in    the    evaluation    of 

project    progress,     and    in    spotting    potential    difficulties    and    developmental 

trends."     IMPACT  supported  the  software  development  process,  furthering  the 

concepts    of    structured    programming    and    module    design     by    fostering    the 

creation    and    integration   of   a    hierarchical    structure   of   program   modules.       In 

preparing    input   for    IMPACT,    a    necessary    discipline   of    planning   was    forced 

upon    the    project    manager,     requiring    him    or    her    to    know    and    define    the 

entities  of  the  project  and  the  relationships   between   them,    such   as 

requirements  and  deliverable  items, 
requirements  and  program  functions, 
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program  functions   and   program  modules, 

high-level    program  modules   and    lower-level    program  modules, 

program   modules   and   equipment, 

deliverable   items   and   the  activities   that   produce  them,    and 

activities   and   the   resources    necessary   to  support   them. 


IMPACT  project  management  tools  were  grouped  into  three  functional 
areas  --  data  base  generation  and  maintenance,  project  planning  and 
control'",  and  report  generation.  The  data  base  generation  and  maintenance 
facility  was  designed  to  be  straightforward  enough  to  make  IMPACT  portable 
to  any  computer  for  the  management  of  system  development.  Data  bases 
were  built  by  providing  such  information  to  IMPACT  as  item  descriptions  and 
activity  management  descriptions.  Data  could  be  inserted  and  processed 
interactively   during  the  development  cycle. 

Project  planning  and  control  involved  three  major  functional  modules-- 
the  Scheduler,  which  derived  and  optimized  critical  path  schedules  and 
resource  allocations;  the  Threader,  which  interpreted  the  hierarchical 
structure  of  the  software  system  and  the  organization  of  project  work  --  a 
manager  or  system  architect  could  direct  the  Threader  to  "pull  a  thread",  to 
trace  the  development  status  of  elements  at  various  levels  of  abstraction; 
and  the  Trender,  which  output  trends  and  anomolies  in  project  performance. 
"These  three  tools  represent  an  integrated  set  of  capabilities  that  help  the 
project  manager  create  and  work  with  his  plans."  Together  they  also 
constituted  a  powerful  project  modeling  capability  designed  to  significantly 
increase  the  project  manager's  efficiency  and  effectiveness.  Furthermore, 
the  report  generation  function  of  IMPACT  provided  access  to  the  information 
stored  in  the  development  and  control  data  bases.  Reports  which  could  be 
requested     included     the     Management     Summary,      Resource     Allocation, 
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Configuration    Index    and    Status,    Configuration    Summary,    Modification    Index, 
Modification   Summary,   and  the  Module  Run   Summary   reports. 

In  addition,  several  processing  tools  were  part  of  the  Factory's 
technological  infrastructure:  Automatic  Documentation  Processor  (AUTODOC) 
produced  program  and  system  documentation,  using  comments  inserted  into 
the  program  modules  by  the  programmer.  Program  Analysis  and  Test  Host^' 
(PATH)  was  a  program  flow  analyzer  that  analyzed  a  source  program  and 
inserted  calls  to  a  recording  program  at  appropriate  locations.  According  to 
SDC,  this  helped  to  provide  information  about  the  structure  of  the  program, 
to  aid  in  thoroughness  of  testing.  Data  Definition  Processor  (DATADEF) 
provided  a  central  means  of  defining  data  for  system  programs  written  in 
several  common  programming  languages  to  assure  that  all  program  modules  of 
the  system  would  have  compatible  references  to  data.  Test  Case  Generator 
(TCG)  was  an  automatic  technique  for  designing  test  data.  Top-Down  System 
Developer  (TOPS)  was  a  modeling  tool  that  provided  the  capability  to 
describe  and  verify  a  design,  as  well  as  describe  much  of  the  control  and 
data   interface  logic  in  the  actual   coding   language. 


III.    INITIAL  PROBLEMS  AND  THE  FACTORY'S  PERFORMANCE 

One  way  to  evaluate  the  results  of  SDC's  factory  approach  to  solve 
what  were  essentially  engineering  problems  is  to  compare  what  the  Software 
Factory  accomplished  in  operation  with  the  five  problems  that  motivated  its 
inception. 
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Probleni  #1 :  Absence  of  a  standardized,  predictable  approach  to  the 
development  process  stemming  from  a  "lack  of  discipline  and 
repeatabilty .  " 

Did  the  Factory  solution  work  in  practicg? 

Yes  and  no.  The  SDC  solution  involved  a  combination  of  technology 
and  management  policy.  On  the  positive  side,  the  historical  data  on  projects 
tracked  through  the  Factory  Support  System  data  bases  made  it  possible  to 
improve  the  predictability  of  future  projects,  as  long  as  managers  used  the 
data  and  engineers  and  other  programmers  repeated  standardized  procedures 
outlined     in    the    Software    Development    Manual.  According    to    Atchley, 

procedures  were  standardized,  with  allowances  for  modifications  over  time, 
and  this  seems  to  have  worked  extremely  well.  Testimony  to  this  is  the  fact 
that  SDC  maintained  the  procedures  developed  for  the  Factory  manual  for  a 
decade. 

On  the  negative  side,  it  seems  that  managers  did  not  effectively  use 
the  data  bases  to  ensure  the  goals  of  discipline,  repeatability,  and 
predictability.  Atchley  claimed  that  during  the  Factory's  earlier  days  nobody 
kept  statistics  on  reuse  rates,  productivity  improvements,  schedule 
completion,  and  program  quality  (inversely  related  to  defect  rates).  This 
made  it  difficult  to  tell  whether  improvements  in  efficiency  or  productivity 
were  directly   related  to  the   Factory  or   not. 
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Problefn  #2:     Project    management    difficulties     stemming    from    a     "lack    of 
development  visibility." 

Did  the  Factory  solution  work  in  practice? 

Yes.  Factory  tools,  integrated  in  the  Factory  Support  System,  tracked 
programmers  through  all  phases  of  the  development  process  and  provided  a 
means  of  visualizing  the  process  flow  and  project  construction.  In 
particular,  the  IMPACT  tool  served  as  a  control  mechanism  for  tracking 
cost  and  schedule,  completion  status,  and  lines  of  authority  and  responsibility 
for  a  project,  throughout  its  development.  During  the  planning  and  system 
definition  phases,  IMPACT  was  used  to  allocate  resources,  check  functional 
designs  against  performance  requirements  to  assess  their  completeness  and 
accuracy,  and  to  generate  reports.  IMPACT  as  well  as  TOPS  provided  visible 
assessments  of  design  completeness,  while  the  PATH  tool  provided  a  more 
quantitative  assessment  of  testing  completeness. 

It  should  also  be  noted  that  these  tools  evolved  over  time  into 
different  versions,  but,  as  indicated  in  the  survey  and  supporting  literature 
on  individual  firms,  the  type  of  technological  infrastructure  Bratman  and 
Court  outlined  for  the  Software  Factory  later  on  became  common  in  large 
software  organizations. 


Problem  #3:  Inability  to  define  accurately  a  customer's  performance 
requirements  at  the  beginning  of  development  or  to  deal  easily 
with  changes  made  during  the  development  process. 
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Did  the  Factory  solution  work  in  practice? 

Yes  and  no  --  or,  rather,  it  worked  as  best  as  could  be  expected  for 
an  engineering  organization  doing  the  type  of  projects  SDC  did.  Portions  of 
the  Software  Development  Manual  can  be  interpreted  as  attempting  to 
capture  company  experience  in  defining  customer  requirements  and  setting 
down  the  best  procedures  available  in  writing.  During  the  development 
process,  tools  such  as  IMPACT  kept  track  of  the  interrelationships  between 
system  components;  consequently,  the  effects  of  requirement  changes  on  the 
system  architecture  were  more  completely  and  easily  determined. 

On  the  other  hand,  SDC  built  so  many  different  types  of  systems  for 
different  machines  and  applications  that  accurately  defining  customer  needs 
before  starting  the  design  process  no  doubt  continued.  This  "problem," 
however,  is  to  a  large  extent  intrinsic  to  the  design  process  except  for  firms 
making  products  with  the  most  stable  and  standardized  features.  Thus,  no 
"factory"  solution  could  have  been  comprehensive,  nor  should  it  be.  But  the 
Factory  infrastructure  was  designed  to  simplify  the  handling  of  design 
changes,    and   seems  to  have  performed  this   function. 

The  Factory  was  not  totally  centralized  and,  according  to  Bratman  and 
Court,  this  appears  to  have  facilitated  the  requirements  definition  process. 
Design,  production,  and  test  activities  were  organizationally  separated, 
pooling  the  technical  resources  of  the  Santa  Monica  facility's  personnel. 
Top-level  visibility  came  through  the  management  of  each  of  these  activities, 
and    provided    at   the   time  of   end-product   turnover   a    natural    point   for   review 
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and  quality  control.  A  program  office  established  for  the  entire  life-cycle  of 
a  project  was  primarily  responsible  for  overall  program  management  and 
control,  customer  (user)  interface,  requirement  and  performance  specification 
generation,  system  engineering,  and  quality  control  and  assurance.  Because 
of  this  allocation  of  responsibilities,  the  program  office  was  not  tied  to  any 
computer  location.  Rather,  the  program  office  was  physically  with  the 
customer/user  in  order  to  maintain  a  smooth  "interface"  with  development 
activities. 


Problem  #4:     Lack  of  tools  for  design  and  verification. 

Did  the  Factory  solution  work  in  practice? 

Yes.  The  Factory  tools  TOPS  and  DATADEF  were  designed  to  provide 
more  automation  and  better  verification  to  the  design  process  and  to  smooth 
the  transition  between  design  and  program  coding.  These  types  of  tools 
have  become  common   in  other  software  facilities. 


Problem  #5:     Lack  of  reusability  of  code. 

Did  the  Factory  solution  work  in  practice? 

No.  There  was  no  tool  specifically  designed  to  combat  the  problem  of 
lack  of  software  reusability.  The  possible  reuse  of  software  was  thought  to 
be  sufficiently  facilitated  by  careful  system  component  structuring,  specific 
relationships    of    software    components    to    performance    requirements,     and 

23 


improved  documentation  inherent  in  Factory-developed  software.  This  did 
not  turn  out  to  be  the  case.  Atchley  recalled  the  beliefs  of  the  Factory 
architects    regarding    reuse  of  code: 


They  felt  that  if  we  used  this  technique  (top-down  program 
design)  and  if  we  used  modules,  that  the  reusability  would  fall  out 
of  it... you  would  decompose  your  requirements  into  functions  and 
come  up  with  code  that  was  modular  and  reusable  by  following  the 
techniques  in  the  SDM.  And  then,  as  a  fallout  of  that,  you  could 
go  back    [to  the  software  library]    and   find   it  and   reuse  it. 


This  did  not  work  because  of  the  different  types  of  programs  SDC 
wrote  and  the  different  types  of  object  computers.  Also,  languages  and 
programming  concepts  available  in  the  mid-1970s  probably  made  this  goal  of 
extensive  reusability  and  portability  too  ambitious.  For  these  reasons,  and 
because  managers  did  not  require  it,  programmers  did  not  even  try  very 
often  to  reuse  components  from  the  library,  which  also  seemed  difficult  to 
use.      Atchley  explained: 


[W]e    changed    machines    from    project    to    project,    and    it    was    very 
difficult    to    reuse    the    code.       We    had    an    electronic    funds    transfer 
program    that    was    done   on    DEC's    PDP-II  .       And    then    we   went   to 
the    Emergency    Command    and    Control    System    for    the    Los    Angeles 
Police    Department    which    was    also    done    on    the    PDP-ll.        And    we 
tried   to   find    some   of   that   software   that   we   could    reuse,    and   some 
of    the    modules.       We    had    not   done    a    good    job    in    EFTS    [Electronic 
Funds    Transfer    System]    of    providing    a    road    map    to    get    it,    even 
using   some  of   the   same   programmers.       They   would   say,      I    know    I 
did    it    and    I    think    we    saved    it;     I'll    go    look    for    it...         ...They 

expressed  a  willingness  verbally  to  do  it,  and  it  sounded  like  a 
good  idea,  but  at  that  time  we  were  unable  to  capture  much.  It 
was  easier  to  do  it  than  to  go  find  it.  If  you  did  find  it  you  had 
to  recode  it  [a  module  in  the  library]  .  Basically,  it  offered  you  a 
detailed  design.  Not  bad,  but  you  had  a  different  database,  a 
different  language,  different  applications,  and  it  was  hard  to  find 
the  building  blocks  that  remained  the  same.  We  were  at  that  time 
doing  the  police  system,  an  air  defense  system,  a  ground  telemetry 
system,  and  an  intelligence  classified  system.  They  were  on  four 
different    machines,     they    had    four    different    sets    of    requirements, 
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and  it  was  very  hard  to  find  any  reusability  or  savings  among  the 
four  of  them.  We  did  set  up  a  library,  where  we  collected  all  the 
software  produced,  filed  it,  and  documented  it.  Usage  of  that 
library  was  very  minimal. 


David  Deaver  described  the  problem  as  relating  to  a  rigid  atmosphere  in 
which  programmers  did  not  like  to  work,  and  a  drastic  change  in  culture  and 
philosophy  that  would  have  been  necessary  to  make  the  Factory  work. 
Programmers  required  retraining  in  order  to  write  and  use  reusable  code; 
there  was  the  additional  problem  of  integrating  someone  else's  previously- 
written  and  perhaps  more  lengthy  code  into  a  new  program,  although  Deaver 
described  the  basis  of  programmers'  resistance  as  "more  a  problem  of 
aesthetics  than  performance."  Programmers  allegedly  did  not  like  the  kinds 
of  programs  relying  on  reused  code  because  all  the  code  was  not  their  own 
and  it  therefore  was  not  as  tight  as  it  could  be,  although  performance  levels 
of  programs  running  with  reused  code  were  in  actuality  not  a  problem. 
There  was,  therefore,  no  real  tradeoff  in  efficiency;  but  programmers' 
happiness  and  sense  of  aesthetics  could   not  be  ignored.^" 

In  1987,  there  was  only  one  programming  project  being  developed  by 
SDC  that  was  reusing  code  from  previously  written  programs.  Atchley 
admitted,  however,  that  this  was  possible  because,  "It's  the  same  machine 
and  the  same  application.  That's  really  simple... no  fights,  no  arguments 
about  it;  we  just  do  it.  And  we're  not  getting  any  static  at  all.  But  when 
the  applications  aren't  the  same,  it's  hard."  SDC  actually  bid  on  this  project 
assuming  it  could  reuse  80%  of  the  program  code  from  existing  SDC  systems. 
Atchley  says  that  the  real  figure  is  turning  out  more  like  50%,  which  he  still 
considers    a    very    high    number.  ^^       When    asked    how    he    felt    about    the    low 
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incidence  of  program  code  reuse  in  the  early  days  of  the  Factory,  Atchley 
commented,  "it's  been  ten  years,  and  we're  now  coming  up  with  an  ability  to 
do  that  .  .  .  the  idea  is  good  but  the  fact  that  it's  taken  us  so  long  ...  is  kind 
of   sad." 


IV.    NEW  PROBLEMS  THE  FACTORY  CREATED 
Work-Flow  Planning  and  Management 

A  serious  "work  flow"  problem  occurred  that  architects  of  the  Factory 
appear  to  have  overlooked.  This  made  it  difficult  for  managers  to  impose 
true  continuity  and  economies  of  scale  and  scope  on  their  development 
operations,  or  learn  from  project  to  project  as  systematically  as  had  been 
hoped. 

In  naming  their  approach  "The  Software  Factory,  "  SDC  managers 
envisioned  an  integrated  organization  of  software  development  standards, 
procedures,  and  tools  which  would  allow  a  less  costly,  higher  quality,  and 
more  efficiently  produced  end  product,  in  much  the  same  way  that  a 
manufacturer  of  hard  goods  organizes  production  activities.  There  was 
supposed  to  be  a  flow  of  "work  in  process"  to  progress  through  various 
stages  of  completion  until  it  reached  the  end  of  the  factory's  line  of  work 
stations,  with  a  centralized  development  data  base  resembling  a  conveyor 
that  carried  an  evolving  product  through  the  production  phases,  as  various 
tools  and  techniques  were  used  to  add  more  and  more  detail  to  the  product 
framework.  The  data  base  seems  to  have  worked  well  and  counterparts  to 
this     tool     can     be     found     in     many     other     large     softwa  re- development 
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organizations. 

Programmers  did  not  seem  to  mind  this  type  of  a  work  flow,  altiiough 
managers  never  required  them  to  drastically  change  their  habits  and,  for 
example,  routinely  reuse  code  from  the  program  library  or  write  reusable 
modules.  Atchley  suggests  that  many  programmers  were  not  even 
particularly  aware  of  what  was  going  on: 


They  didn't  even  know  it  happened.  It  was  a  term  used  and  a 
way  of  doing  work,  but  as  far  as  most  of  the  programmers  were 
concerned,  life  went  on  as  usual.  I  don't  think  there  was  any 
great  culture  shock  or  resistance  to  it.  They  knew  the  term,  they 
knew  they  had  been  gathered  from  the  various  four  corners  of  the 
company  and  put  together,  but  they  didn't  consider  themselves  in 
a  factory.  There  were  lots  of  cartoons  on  the  wall  about  the 
Factory  and  all  these  kinds  of  things,  but  truthfully  I  don't  think 
the  programmers  considered  themselves  factory  workers. 


A  far  more  serious  problem  was  that  the  nature  of  SDC's  business, 
planning,  and  management  practices  made  it  difficult  to  implement  the  "flow" 
concept  as  intended.  Because  projects  came  about  on  a  contract  basis,  there 
was  not  a  constant  flow  of  work  to  feed  the  Factory.  When  the  work  level 
dropped,  SDC  also  continued  its  custom  of  laying  off  even  trained  people. 
Atchley  admitted  the  lack  of  work  undermined  the  factory  concept,  although 
he  also  saw  this   as  a  failure  of  production   planning: 


We  did  not  have  the  work  to  sustain  it.  If  you  were  going  to  have  a 
factory,  and  the  work  wasn't  coming  through  all  the  time,  then  you  had 
these  ups  and  downs.  You  somehow  had  to  provide  the  flywheel  money, 
some  other  projects,  to  keep  people  between  programs.  No  one  was 
willing  to  make  the  sustaining  investment  to  keep  a  flywheel  going  .  .  . 
there  was  no  planning  to  take  care  of  that.  .  .  Every  job  was  totally 
different.         It    would    work    a    lot    better    if    we    had    a    specific    line    of 
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business , 


"Matrix"  Management 

A  related  problem  was  that  the  Software  Factory  in  effect  created  a 
type  of  matrix  management  whereby  there  were  project  managers  responsible 
for  dealing  directly  with  customers  and  then  managers  in  the  Factory 
responsible  for  producing  the  actual  software.  In  principle,  this  was  no 
different  from  non-software  firms  that  had  product  or  project  managers  who 
developed  products  jointly  with  manufacturing  imput  and  then  let 
manufacturing  take  care  of  final  production.  But  SDC  appears  to  have 
created  the  Factory  without  anticipating  the  difficulties  of  matrix 
management  or   preparing    its   managers   to  accept   the   new   structure. 
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Software   Factory  Organizational    Principles 
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As  shown  in  the  figure  outlining  the  Factory  s  organizational  principles, 
the  software  requirements  of  a  major  project  were  done  "independent  of  the 
program,  "  the  program  being  a  large  contracted  project.  Atchley  recalled 
the  discord  this  created  when  a  project  manager  suddenly  was  no  longer  in 
control  of  development  activities: 


We  didn't  have  the  management  tools  in  place  .  .  .  what  happens  is 
that  you've  got  a  program  manager  who's  come  to  you  with  his 
program  and  he's  given  you  the  task  to  do,  but  really  he  doesn't 
have  any  control  over  you.  And  if  you  overspend,  what's  he 
going  to  do?  He  has  to  have  the  job  done.  So  there  was  not 
enough  incentive  on  the  part  of  the  factory  to  produce  at  an 
economical  cost  .  .  .  [These]  were  the  complaints  of  the  other 
managers.  It  was  costing  them  money  ...  there  were  some 
complaints  about  the  fact  that  now  they  had  two  managers,  that 
they  had  doubled  the  overhead  .  .  .  since  you  had  the  management 
of  the  Software  Factory  but  you  still  had  the  management  of  the 
program.      So  there  were  some  complaints   about  that.  .  . 

Some  managers  accepted  the  Factory  concept  as  a  viable  structure  for 
software  development,  and  were  even  excited  about  it  with  hopes  for  its 
success.  But  others,  according  to  Atchley,  seemed  to  feel  they  were  losing 
their  influence  on  the  software  development  processes  over  which  they  had 
control : 


Some  of  the  managers  felt  they  were  losing  their  turfdom  "  .  .  .  we  took 
a  lot  of  people  who'd  been  program  managers  and  we  consolidated  into 
three  areas.  That  left  some  men  and  women  at  that  same  level  who  no 
longer  had  a  direct  influence,  and  they  became  plans  and  programs 
people.  ..  they  were  in  the  situation  of  getting  their  projects  done  by  the 
Software  Factory.  That  left  some  of  those  people  uneasy...  They 
wanted  their  hands  on  that.  They  wanted  to  be  able  to  touch  their 
programmer.  So     there     was     a     lot     of     resistance     from     program 

management   to   the   idea.       There   still    is. 
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These  "plans  and  programs  people"  served  as  the  interface  between  the 
Factory  and  the  program  office,  remaining  with  the  customer.  After  the  end 
of  the  Factory  experiment,  programmers  then  went  with  the  programs  people 
to  the  customer's   site  to  do  actual  development: 


[Plans  and  programs  people]  chase  new  programs,  help  the 
proposals,  help  develop  the  new  business,  go  out  and  talk  to 
customers,  help  with  the  strategic  planning,  determine  where  we 
are  going  in  a  particular  line  of  business,  become  experts  in  that 
line  of  business,  and  when  we  win  contracts  they  become  the 
interface  out  of  the  program  office  with  the  Factory.  They  are  a 
part  of  the  organization.  They  used  to  give  us  the  specs  and  say 
'Go  produce  this  software.'  The  plans  and  programs  person  would 
be  the  interface,  and  he  would  be  controlling  the  budget  ...  As  it 
Is  now,  we  [program  implementation]  are  a  part  of  the  program 
office;  we  work  in  their  area,  physically.  We  moved  the  people 
into  that  physical  area;  we  no  longer  keep  the  people  physically 
separated    [from  the  program  office] . 


V.    FATE  OF  THE  SDC  SOFTWARE  FACTORY 
Decentra  I  ization 

Because  the  Factory  as  attempted  at  SDC  created  problems  as  well  as 
solved  them,  management  gradually  dispersed  the  Santa  Monica  programmers 
into  different  functional  areas  by  assigning  them  to  different  customer 
sites. ^^  In  general,  this  was  the  strategy  SDC  has  followed  for  the  past 
decade,  although,  organizationally,  management  has  tried  to  focus  particular 
facilities  on  specialized  lines  of  business.  Most  firms,  however,  according  to 
the  survey,  were  more  centralized  than  SDC.  Atchley  admitted  as  well  that 
even  SDC's  Paoli  (Pennsylvania)  facility  successfully  adopted  the  concept  of 
work  coming  into  one  large  facility  where  factory-type  productivity  tools  can 
be   systematically  applied,    even   though    Paoli   does   not   use  the  term   "Software 

31 


Factory"  (which  remains  an  SDC  trademark).  The  attempt  at  Santa  Monica 
simply  did  not  work  out  as  well  as  intended.  Some  of  the  Factory  discipline 
and  procedures  remained  while  the  physical  centralization  and  notions  of  a 
centralized  factory  work  flow  and  technological  infrastructure  disappeared. 
As   Atchley   explained,    the  factory  workers    now  go  to  the  work: 


You  would  not  see  a  sign  in  this  building  that  said  Software 
Factory.'  ...  We've  moved  on  ...  All  the  tools  weren't  there;  some 
were,  some  weren't.  The  concepts  were  there,  the  ideas  were 
there,  but  it  wasn't  all  there.  ...  They  weren't  really  dismantled. 
They  were  in  disuse  because  new  ones  came  along,  and  we  just  no 
longer  used  them.  The  only  thing  we're  still  using,  and  we  won't 
use  it  much  longer,  is  PDL  [a  Program  Development  Language  SDC 
developed  for  in-house  use].  We're  still  using  it,  but  we're  going 
to  BYRON  [a  commercial  product],  and  within  the  next  six  months, 
we're  going  to  be  all  converted  over  to  BYRON.  ...  PDL  was  a 
Pascal-based  system.  That's  the  only  thing  left  that  we're  still 
using.  We're  moving  to  ARGUS,  we're  using  a  new  editor.  Times 
change  .  .  .  What  we're  trying  to  do  now  is  establish  a  common 
software  environment  where  we  provide  tools  and  the  environment 
to  develop  software  from  the  beginning  up  to  the  coding  stage. 
.  .  .We  provide  the  cadre  of  people  to  do  the  job  as  opposed  to 
taking  the  job  into  the  factory.  In  Paoli,  they're  still  running  the 
other  way.  But  in  Santa  Monica,  we've  drifted  from  that  quite  a 
bit.  We  still  have  the  disciplines,  standards,  and  concept,  but  the 
work  does  not  flow  through  the  factory.  The  Factory  workers  go 
to  the  work. 


Atchley's  final  assessment  of  the  factory  experiment  was  generally 
positive.  Aside  from  the  work  flow  and  management  problems,  improvements 
in  efficiency  were  not  obviously  attributable  to  the  Factory,  perhaps  because 
the  system  did  not  focus  on  productivity  and  reusability,  unlike  other  factory 
approaches,  such  as  at  Toshiba.  On  the  other  hand,  he  believed  the  Factory 
increased  awareness  among  software  engineers  of  the  product  life  cycle,  and 
greatly  improved  quality  through  a  structured  approach  and  more  formalized 
testing   procedures. 
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I  think  that  while  we  may  not  be  organized  the  way  we  were,  our 
people  are  more  aware  of  the  software  life  cycle  now.  I  seriously 
doubt  that  it  [the  Factory]  reduced  cost.  Were  the  people  more 
efficient?  It's  hard  to  say  they  were  more  efficient  because  of 
the  Factory  or  that  they  became  more  efficient  because  we  became 
more  efficient.  I  presume  there  was  a  fallout  there  on  efficiency 
and  productivity.  I  think  the  structured  approach  helped  quality 
immensely.  I  think  the  fact  that  we  became  very  formal  with  the 
independent  test  organization  improved  the  quality  of  the  product 
we  delivered.  Whether  that  was  the  Software  Factory  or  not,  I 
don't  know. 


Atchley,  as  well  as  Deaver,  also  felt  the  Factory  concept  was  workable  and 
had  potential  for  real  factory-type  improvements  in  productivity.  SDC, 
however,  has  not  done  much  with  the  idea  beyond  the  standardization  of 
procedures  and  the  greater  work-flow  centralization  at  Paoli.  Atchley 
concluded: 


I  think  it's  a  good  concept.  I  think  discipline  can  be  applied  to 
the  software  development  process.  I  think  that  reusability  and 
productivity  should  be  the  main  factors  out  of  it.  We're  not  doing 
as  good  a  job  today  as  we  were  ten  years  ago  in  keeping  it  alive. 
We've  made  a  lot  of  progress,  but  we  could  be  better  if  we  had 
really  actively  pursued  the  concept  and  grown  the  concept  as  new 
ideas  came  out  of  the  schools  and  papers  were  written.  If  we'd 
kept  the  factory  concept  more  prominent,  I  think  we  would  have 
been  able  to  put  more  of  those  ideas  in  sooner.  As  it  is  now, 
there's  a  lag.  Instead  of  being  at  the  forefront,  we're  kind  of 
dragging. 


The  Survey  Response 

Another  way  to  gauge  the  impact  as  of  1987  of  the  Software  Factory 
experiment  on  SDC  is  from  the  company's  "performance"  in  the  survey  of  38 
large-scale    software   facilities    or   firms    in    the    U.S.    and   Japan    (21    U.S.,    17 
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Japanese).  The  SDC/Unisys  response  (from  Atchley)  covered  general 
company  practices.  As  noted  earlier,  these  questions  were  largely  based  on 
the  1975-77  SDC  articles  describing  the  Factory's  technology,  policies,  and 
objectives. 

SDC/Unisys  did  not  come  out  well  in  the  8  technology  criteria,  where 
it  ranked  22nd  (72%,  one  percent  above  the  mean  for  38  facilities).  Effects 
of  the  factory  experiment  seem  more  obvious  in  the  policy  area,  toward 
which  the  total  model  is  biased.  SDC/Unisys  ranked  9th  in  the  15 
policy/methodology  criteria  (77%,  13  percent  above  the  mean),  and  llth 
overall  (75%,  8  percent  above  the  mean).  Furthermore,  among  U.S.  firms  and 
facilities  studied,  despite  a  place  of  10th  in  technology,  SDC/Unisys  ranked 
2nd   in   policy   and  3rd  overall    (see  Appendix   tables). 

MEANS  AND  STANDARD  DEVIATIONS  FOR  SURVEY  QUESTIONS 

SURVEY  ANSWERS   KEY: 

4  =     CAPABILITY  OR   POLICY   IS   FULLY   USED  OR   ENFORCED 

3  =     CAPABILITY  OR   POLICY    IS   FREQUENTLY   USED  OR   ENFORCED 

2  =     CAPABILITY  OR   POLICY    IS   SOMETIMES   USED  OR   ENFORCED 

1    =     CAPABILITY  OR   POLICY    IS   SELDOM   USED  OR   ENFORCED 

0  =      CAPABILITY   OR    POLICY    IS    NOT   USED 

n   =  38   (Jap.    =   17,    U.S.    =  21) 

I.    TECHNOLOGY/FACILITY  INFRASTRUCTURE 


ALL 

COMPANIES/FACILITIES 

U.S. 

All  Coinpanies    Japanese 

Question 

Mean 

S.    Dev.      Mean 

S.    Dev. 

MMn 

S.    Dev. 

A 

3.47 

0.62         3.38 

0.65 

3.55 

0.58 

B 

3.45 

0.71         3  69 

0.48 

3.25 

0.79 

C 

3.07 

1.02         2.97 

0.87 

3.15 

1.13 

D 

2.55 

1  . 04         2 . 99 

0.67 

2.20 

1.14 

E 

2.68 

1.18         2.44 

1.17 

2.88 

1.15 

F 

3.04 

1 . 08         3 . 40 

0.86 

2.75 

1.14 
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G 

2.67 

1.25 

2.94 

1.08 

2.45 

1.34 

H 

1.85 

1.06 

2.37 

0.82 

1.43 

1.04 

APPLICATIONS  COMPANIES/FACILITIES 

A 

3.35 

0.62 

3.15 

0.71 

3.50 

0.50 

B 

3.31 

0.76 

3.58 

0.52 

3.12 

0.84 

C 

2.97 

1.10 

2.70 

0.93 

3.16 

1.18 

D 

2.54 

0.93 

2.83 

0.67 

2.33 

1.03 

E 

2.65 

1.25 

2.20 

1.27 

2.96 

1.14 

F 

2.84 

1.18 

3.23 

0.98 

2.56 

1.24 

G 

2.54 

1.36 

2.75 

1.66 

2.39 

1.39 

H 

1.86 

1.04 

2.38 

0.64 

1.50 

1.12 

A.  Centralization  of  development  for  a  distinct  software  product  family  in 
a  single  location  or  directly  linked  sites  operating  as  an  integrated 
unit,    rather  than  decentralizing  development  in   independent  sites. 

SDC:       3  This    was    below    the    mean     responses    for    the    total 

sample  and  U.S.  and  Japanese  firms,  and  reflects 
SDC's  combination  of  decentralization  into  different 
locations,  although  the  firm  is  attempting  to  focus 
each  location  on  a  particular  line  of  business.  Some 
examples  from  the  survey  comments  were  Santa 
Monica  (network  systems),  Camarillo  (air  defense 
systems),  Eagan,  Minn,  (air  traffic  control),  and 
Huntsville  (Strategic  Defense   Initiative). 

B.  A  uniform  set  of  specification,  design,  coding,  testing,  and 
documentation  procedures  used  among  project  groups  within  a 
centralized  facility  or  across  different  sites  working  on  the  same 
product  family  to  facilitate  standardization  of  practices  and/or  division 
of  labor  for  programming  tasks  and   related  activities. 

SDC:       2  This    was    considerably    below    the    averages    for    U.S. 

and  Japanese  firms.  According  to  SDC,  the 
changeover  from  Burroughs  ownership  to  Unisys  in 
1986  has  forced  the  company  to  "start  over"  in 
establishing   standards   and   procedures. 

C.  A  centralized  program  library  system  to  store  modules  and 
documentation. 

SDC:        2  This    was    also    below    average.        SDC    had    problems 

getting  programmers  to  use  the  central  program 
library  in  the  Software  Factory.  The  1987  response 
indicated    that    SDC    maintained     such     a     library    but 
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'it's   not   used  as   frequently  as   we  would   like. 


A  central  production  or  development  data  base  connecting  programming 
groups  working  on  a  single  product  family  to  track  information  on 
milestones,  task  completion,  resources,  and  system  components,  to 
facilitate  overall  project  control  and  to  serve  as  a  data  source  for 
statistics  on    programmer  productivity,    costs,    scheduling   accuracy,    etc. 

SDC:        3  This     response    was    above    the    mean    for    the    sample, 

and  higher  than  thae  average  U.S.  applications 
response,  although  it  would  have  been  average  for 
the  Japanese  firms.  SDC  reported  that  their  central 
data  base  was  project  or  line-of-business  (facility) 
oriented;  this  was  the  usual  practice  in  other  firms 
as   well. 


E.  Project  data  bases  standardized  for  all  groups  working  on  the  same 
product  components,  to  support  consistency  in  building  of  program 
modules,  configuration  management,  documentation,  maintenance,  and 
potential    reusability  of  code. 

SDC:        4  This    answer    was    considerably    above    average,     and, 

again,  seems  to  reflect  the  continuing  influence  of  a 
factory-type  approach   to  development. 

F.  A  specific  group  or  groups  designated  to  develop  and  disseminate 
methodologies  and  tools  to  automate  tasks  such  as  requirements 
specification  and  design,  coding,  documentation,  system  testing  and 
debugging,  as  well  as  to  facilitate  standardization  of  practices  and 
division  of  labor,  and  effective  managerial  control  over  all  programming 
activities. 

SDC:        4  Above  average,    especially  for  U.S.    firms. 

G.  A  system  interface  providing  the  capability  to  link  support  tools, 
project  data  bases,  the  centralized  production  data  base  and  program 
libraries. 

SDC:        3  This    answer    was     above    the    sample    mean    and    above 

average  for  a  U.S.  response  but  equal  to  the 
Japanese  average.  SDC  also  reported  this  interface, 
which  had  been  described  in  the  Software  Factory 
experiment,    was    "still   evolving.  " 

H.  Automated  or  semi -automated  integration  of  applicable  data  from 
support  tools  and  development  data  bases  with  management  control 
systems    (project   data    bases    and    the   central    production    data    base),    for 
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each  phase  of  program  development;  and  the  utilization  of  this 
capability  to  facilitate  budgeting,  forecasting,  maintenance,  and  overall 
llfe-cyle  cost  control  on  current  and  future  projects. 


SDC: 


This  was  above  the  sample  mean,  which  was  low  due 
to  the  U.S.  average.  SDC  also  commented  that  "This 
is  the  goal   --   it  might  be  a  dream." 


II.      METHODOLOGY  &  POLICY   INFRASTRUCTURE 


ALL  COMPANIES/FACILITIES 

U.S. 

All  Companies 

Japanese 

Question           Mean  S 

.    Dev. 

Means 

.   Dev. 

Means 

.  Dev. 

A 

1.77 

1.20 

1.85 

1.14 

1.71 

1.24 

B 

2.50 

1.30 

2.98 

1.08 

2.16 

1.34 

C 

3.33 

0.89 

3.55 

0.65 

3.18 

0.99 

D 

2.00 

1.11 

2.05 

1.21 

1.96 

1.03 

E 

2.81 

1.07 

3.20 

0.95 

2.54 

1.06 

F 

2.67 

0.98 

3.30 

0.60 

2.21 

0.94 

G 

2.46 

1.16 

2.75 

1.17 

2.25 

1.11 

H 

2.07 

1.28 

2.88 

0.85 

1.50 

1.22 

1 

1.99 

1.04 

2.58 

0.87 

1.57 

0.94 

J 

2.53 

1.25 

2.90 

1.24 

2.26 

1.19 

K 

1.94 

1.27 

2.33 

1.43 

1.67 

1.05 

L 

2.90 

1.17 

2.75 

1.29 

3.01 

1.06 

M 

3.18 

1.10 

3.65 

0.63 

2.85 

1.24 

N 

2.71 

1.03 

3.13 

0.75 

2.42 

1.10 

0 

2.61 

1.13 

3.48 

0.53 

2.00 

1.04 

APPLICATIONS  COMPANIES/FACILITIES 

A 
B 
C 
D 

E 

F 

G 

H 

I 

J 

K 

L 

M 

N 

O 


1.77 
2.50 
3.33 
2.00 
2.81 
2.67 
2.46 
2.07 
1.99 
2.53 
1.94 
2.90 
3.18 
2.71 
2.61 


1.20 
1.30 
0.89 
1.11 
1.07 
0.98 
1.16 
1.28 
1.04 
1.25 
1.27 
1.17 
1.10 
1.03 
1.13 


1.85 
2.98 
3.55 


2. 
3. 

3, 
2. 
2. 
2. 


.05 
20 
.30 
,75 
.88 
58 
2.90 
2.33 
2.75 
3.65 
3.13 
3.48 


1.14 
1.08 
0.65 
1.21 
0.95 
0.60 
1.17 
0.85 
0.87 
1.24 
1.43 
1.29 
0.63 
0.75 
0.53 


71 
16 
18 
96 
54 
21 
25 
50 
1.57 
2.26 
1.67 
3.01 
2.85 
2.42 
2.00 


1.24 
1.34 
0.99 
1.03 
1.06 
0.94 
1.11 
1.22 
0.94 
1.19 
1.05 
1.06 
1.24 
1.10 
1.04 
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A.  Use  of  a   standardized   design    language 

SDC:        4  This    was    double    the    average    response.       SDC    used    a 

tool  it  had  developed  based  on  Yourdon  and  using 
the   UNIX  operating   system. 

B.  Use  of  a   standardized   module-specification    language 

SDC:        3  This     was     above     the     mean,     though     equal     to     the 

Japanese  average.  SDC  continued  to  use  PDL,  which 
it  had  developed  for  the  Software  Factory,  though  it 
was   changing   to   Byron. 

C.  Use  of  a    standardized   coding   language 

SDC:        2  This    was    below    average.        For    most    projects,     SDC 

used  C,  but  new  programs  used  Ada,  and  others  used 
Algol,  Fortran,  Pascal,  Jovial,  and  CMS2.  The  range 
of  languages  reflected  the  diversity  of  SDC  products 
and  customers. 


D.  Emphasis    on    high-level    abstraction    (data-type  or   procedure  abstraction; 
object   rather  than   variable  orientation) 

SDC:        3  Above  average. 

E.  Planning  for  maintainability  at  the  module-design   level 

SDC:        4  Above    average.        SDC    claimed    to    place    the    highest 

emphasis   on   this,    along   with   the  ability   to  test. 

F.  Planning  for   reusability  at  the  module-design   level 

SDC:        3  This    was    an    average    response,    although    higher    than 

the   U.S.    averages 

G.  Planning  for  portability  at  the  module-design   level 
SDC:        3  Above  average. 

H.       Monitoring  of   how  much   code   is   being   reused 

SDC:        3  Above    average,     and     especial     higher    than     the    U.S. 
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responses.  As  noted  in  the  data  summary  above,  the 
overall  means  for  this  question  was  3.16  for  Japanese 
and  1.29  for  U.S.   facilities. 


I.  "Layering"  of  reused  modules  from  the  program  library,  along  with 
newly  written  code,   to  create  new  programs 

SDC:        2  This    was    an    average    response.        Layering    can    be 

interpreted  as  a  factory-type  approach  to  program 
development  in  that  it  is  an  effective  way  to 
combine  existing  modules  with  new  code,  as  well  as 
develop  programs  that  have  distince  components  and 
are  thus  more  easily  maintainable  or  transferred  to 
different  computers   (portable). 

J.  Cataloging  for  the  program  library  of  common  functional  modules  (e.g.  a 
date  verification   routine) 

SDC:        2  Below  the  sample  mean   but  average  for  the  U.S. 

K.  Cataloging  for  the  program  library  of  data  abstraction  modules  (e.g. 
table  or  linked-list  managers) 

SDC:       2  Average    for    the    sample;     somewhat    high    for    a    U.S. 

facility  though   still   below  the  Japanese  mean. 

L.  Writing  of  documentation  to  accompany  modules  placed  in  the  program 
library 

SDC:        3  Average. 

M.  Requirement  that,  if  changes  are  made  in  the  code  of  a  module  in  the 
program  library,    the  documentation   must  also  be  changed 

SDC:        4  Above   average   for   the   sample;    equal    to   the   Japanese 

average. 

N.  Formal  management  promotion  (beyond  the  discretion  of  individual 
project  managers)  that  new  code  be  written  in  modular  form  with  the 
intention  that  modules  (in  addition  to  common  subroutines)  will  then 
serve  as   reusable  "units  of  production"   in   future  projects 

SDC:        4  Considerably     higher    than     the     sample     mean     and 

especially  high  for  a  U.S.   facility. 
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O.  Formal  management  promotion  (beyond  the  discretion  of  individual 
project  managers)  that,  if  a  module  designed  to  perform  a  specific 
function  (in  addition  to  common  subroutines)  is  in  the  program  library 
system,    rather  than   duplicating    such    a   module,    it   should   be   reused 

SDC:        4  Considerably     higher     than     the     sample    mean     and 

especially   high   for  a   U.S.    facility. 


VI.    SUBSEQUENT  U.S.    DEVELOPMENTS 

In  his  now-classic  essay  on  software  engineering  published  in  1975, 
The  Mythical  Man-Month,  Frederick  P.  Brooks,  Jr.,  discussed  problems  very 
similar  to  what  Bratman  and  Court  had  identified . -^^  Based  on  his  experience 
with  OS/360,  Brooks  set  the  tenor  for  development  of  software  engineering 
in  IBM,  and  he  did  so  promoting  approaches  that,  with  the  exception  of  his 
suggestion  to  limit  the  number  of  people  on  one  project,  have  generally  been 
incorporated  into  software  factories  and  improvement  efforts  in  a  variety  of 
firms:  (1)  Consideration  of  sequential  constraints  and  the  number  of 
independent  subtasks  (pp.  25-26),  and  use  of  concrete  milestones,  PERT 
charts  or  critcal  path  analysis  (pp.  154-158),  to  deal  with  poorly  developed 
estimating  techniques  and  methods  to  monitor  schedule  progress  (pp.  16-20). 
(2)  The  team  approach  (pp.  31-37)  and  software  tools  such  as  high-level 
languages  (p.  93)  to  deal  with  a  wide  discrepancy  in  the  performance  even  of 
experienced  programmers  (p. 30),  and  the  difficulty  of  increasing  individual 
programmer  productivity.  (3)  The  use  of  precise  written  specifications, 
formal  definitions,  system  of  formal  conferences  and  other  techniques  to 
improve  communication  (pp.  62-69)  and  overcome  the  difficulty  of  achieving 
"efficiency     and     conceptual     integrity"     in     a     large     project     with     many 
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participants  (pp.  31).  (4)  Use  of  pilot  systems  and  systems  designed  for 
change  through  careful  modularization  using  top-down  design,  extensive 
subroutining  and  definition  of  intermodule  interfaces,  complete 
documentation,  standard  calling  sequences  and  table-driven  techniques,  and 
the  use  of  very-high-level  languages  and  self-documenting  techniques  (pp. 
117-118),  to  deal  with  frequent  alterations  in  specifications  that  delayed 
progress  in  development  and  testing.  (5)  Better  testing  techniques  and  tools 
such  as  top-down  design  and  structured  programming  (pp.  142-144)  to  reduce 
bugs  and  overcome  difficulties  in  system  debugging  and  program  maintenance 
(pp.    120-121). 

A  recent  article  by  R.  Goldberg,  a  consultant  at  the  IBM  Software 
Engineering  Institute,  outlined  the  progress  IBM  and  other  firms  have  made 
In  developing  or  using  these  tools  and  techniques.  According  to  Goldberg,  in 
the  late  1960s,  when  OS/360  and  other  projects  prompted  the  application  of 
engineering-type  practices  to  software,  the  field  was  limited  to  a 
management  focus  on  the  individual  engineer  or  programmer  and  a 
technological  focus  on  techniques  such  as  structured  programming.  In  the 
next  stage,  roughly  during  the  1970s,  experimental  techniques  such  as  Brooks 
recommended  became  more  formal  methodologies,  such  as  stepwise  refinement 
or  structured  analysis.  Managers,  in  turn,  began  to  direct  more  of  their 
attention  to  understanding  better  the  processes  involved  in  each  step  of 
software  life-cycle  development  (for  example,  from  basic  design  through 
maintenance).  In  the  most  recent  stage  (the  1980s),  companies  have  pushed 
technology  development  more  toward  improving  software  environments,  as 
managers   have  shifted  their  concerns  more  to  process-management  issues. •^'^ 
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The  result  of  this  evolution,  drawing  on  two  decades  of  research, 
development,  and  experience,  is  a  huge  literature  covering  topics  discussed 
by  Brooks,  Bratman  and  Court,  as  well  as  many  other  authors  in  the  1970s: 
structured  design,  project  management,  software  engineering  economics, 
requirements  definition,  language  development,  modular  programming,  data 
structures,  psychological  or  human  factors  in  programming,  productivity 
measurements,  team  programming  concepts  and  tools,  software  quality, 
maintenance,  cost  estimation,  life-cycle  control,  configuration  management, 
large-program  management,  documentation,  flow  diagrams,  testing,  reusability, 
prototyping,  and  the  like.  "^  A  full  review  of  subsequent  developments  in 
software  engineering  is  beyond  the  scope  of  this  paper,  although  a  sampling 
of  sevel  ideas,  company  experiences,  and  trends  suggests  some  of  the 
directions   U.S.    firms   have  taken. 


The  survey  indicates  that  TRW  was  a  leader  in  the  entire  sample  and 
the  leader  among  U.S.  respondents  in  applying  factory-type  discipline  and 
tools  to  software  development  (see  Appendix).  Much  of  this  is  due  to  Barry 
Boehm  of  TRW,  who  has  written  extensively  on  software  engineering  and 
economics  for  more  than  a  decade.  His  ideas  and  experiments  in  TRW  have 
been  extremely  influential  in  the  U.S.  and  abroad  The  type  of  controlled 
environment  offered  by  a  factory  model  clearly  supported  the  type  of 
learning  environment  Boehm  advocated  for  TRW,  except  for  the  question 
perhaps  of   how  many   people  should   be  involved   in  one  project. 
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In  a  key  1976  article  that  helped  to  define  the  field  of  software 
engineering,  Boehm  discussed  integrated  approaches  to  software  development, 
citing  the  objectives  of  such  approaches  as  "a  significant  boost  in  software 
development  efficiency  and  quality  through  the  synergism  of  a  unified 
approach."  He  cited  as  examples  a  complementary  development  approach  and 
set  of  programming  standards;  the  ability  to  perform  a  software  update  and 
at  the  same  time  perform  a  set  of  timely,  consistent  project  status  updates; 
or  simply  the  improvement  in  software  system  integration  achieved  when  all 
participants  are  using  the  same  development  concept,  ground  rules,  and 
support  software.  ^  Strategies  Boehm  seemed  to  recommend  were  IBM's 
"top-down  structured  programming  with  chief  programmer  teams"  concept,  as 
well  as  SofTech's  structured  integrated  approach  and  TRW's  management- 
intensive  integrated  approach.  The  System  Design  Laboratory  (SDL)  at  the 
Naval  Electronics  Laboratory  Center  was  also  engaged  in  an  integrated 
approach  to  software  development. 

In  a  1977  article,  Boehm  described  the  results  of  one  in  a  series  of 
efforts  at  TRW  to  define  a  set  of  principles  to  "guarantee"  a  successful 
outcome  to  a   software  development  effort: 

1.  Manage  using  a  sequential   life-cycle  plan 

2.  Perform  continuous  validation 

3.  Maintain   disciplined   product  control 

4.  Use  enhanced  top-down   structured   programming 

5.  Maintain  clear  accountability  for   results 
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6.  Use  better  and   fewer   people 

7.  Maintain     a     commitment    to    improve    the    process^^ 


In  contrast  to  software-factory  notions  of  large  scales  of  people  in  one  site, 
one  of  these  principles  recommended  fewer  people  on  projects;  so  did 
Frederick  Brooks  of  IBM,  based  on  the  experience  of  having  developed  the 
System  360  operating  system,  although  Japanese  software-factory  managers 
claimed  they  were  able  to  add  people  to  projects  falling  behind  and  get  them 
done  on  time.'^°  As  Hitachi  has  found  as  well,  Boehm  suggested  that 
reliance  on  outstanding  project  personnel  alone  is  not  sufficient  to  ensure  a 
successful  software  development  effort.  Neither  are  techniques  now 
practiced  almost  universally,  such  as  top-down  structured  programming, 
sufficient  in  themselves.  But  he  did  maintain  that  the  continued  learning 
and  application  of  these  principles  over  the  entire  life-cycles  of  successive 
projects  would  bring  forth  improvements  in  project  understanding  and 
gradual  overcoming  of  management  complexities. 

In  a  1984  article,  Boehm  and  his  co-authors  cited  the  recognition  by 
software  managers  of  several  "corporate  motivating  factors"  which  were 
leading  to  a  more  substantial  level  of  investment  in  software  process 
technology  and  productivity  improvement.  These  factors  included  increased 
demand  for  software,  limited  supply  of  software  engineers,  reduced  hardware 
costs,  and  rising  software-engineering  support  expectations.'^'  A  software 
productivity  study  TRW  did  in  1980  identified  several  ways  for  improving 
productivity  in  software  development,  recommending  evolutionary 
development,     or    prototyping,     of     requirements     specifications,     to    facilitate 
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changing  and  better  understood  user  needs,  and  more  emphasis  on  training  of 
system  users  through  improved  documentation,  consulting,  and  in-house 
courses,  and  on  such  organizational  factors  as  project  learning  and  system 
usage  measurement.  Preliminary  conclusions  from  the  study  included  better 
integration  of  programmer  initiatives  with  productivity  improvement  tools. 
All  these  strategies  are  not  only  consistent  with  a  software  factory  model 
but,  indeed,  have  been  incorporated  in  actual  software  factories  such  as 
Toshiba. 28 

In  general,  Boehm  in  a  1983  article  concluded  that  the  shortage  of 
software  engineers  and  rising  demand  for  programs  necessitated  that  firms 
seek  a  combination  of  reliability,  affordability,  and  adaptability  in  their 
development  efforts.  Several  studies  using  a  model  Boehm  developed  for 
software  cost-productivity  estimating  also  came  to  three  conlcusions  that 
strongly  support  long-term,  integrated  factory-type  efforts  such  as  at 
Toshiba,  Hitachi,  and  NEC:  (1)  Significant  productivity  gains  require  an 
integrated  program  of  initiatives  in  several  areas,  including  tools,  methods, 
work  environments,  education,  management,  personal  incentives,  and 
reusability.  (2)  An  integrated  software  productivity  program  can  produce 
productivity  gains  of  factors  of  two  in  five  years  and  factors  of  four  in  ten 
years,  with  proper  planning  and  investment.  (3)  Improving  software 
productivity   involves  a   long,    sustained  effort  and  commitment.  "^^ 


Whereas     Boehm    has     succeeded    in     implementing    these    ideas    in    TRW, 
GTE's    experience    reflects    the    problems    a    diversified    organization    faces    in 
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attempting  to  apply  corporate  standards  and  general-use  tools  to  software 
development.-^^  Its  Corporate  Software  Developwient  lltethodoloqv,  published 
in  1980,  incorporated  the  ideas  embodied  in  existing  methodologies  used  in 
several  GTE  divisions.  According  to  William  G.  Griffin,  director  of  the 
Computer  Science  Laboratory  at  GTE  Laboratories,  Inc.,  the  methodology 
consisted  of  several  general  objectives  that  represented  good  practice  and 
met   little  opposition: 


1.  A  specified  software  architecture  for  all  systems, 
represented  as  a  hierarchy  of  logical  components, 
each  level  of  the  hierarchy  being  a  decomposition 
of  the  preceding    higher   level 

2.  A  detailed  description  of  the  development  process 
based  on   the   software   life-cycle  model 

3.  A  description  of  the  necessary  aspects  of 
configuration   management 

4.  A  list  of  the  necessary  documentation  for  each 
phase  of  the  development  process 

5.  A  glossary  of  terms  and  prescribed  structure 
chart  symbols 


Development  of  this  manual  was  one  of  several  steps  GTE  took 
following  the  formation  of  a  Software  Steering  Committee,  whose  tasks 
included  studying  software  engineering  and  management  issues,  examining  the 
diverse  software  activities  within  the  corporation,  and  promoting  the  sharing 
of  experiences  and  software  engineering  tools.  The  greatest  benefit  Griffin 
cited  from  this  centralized  approach  was  the  ability  of  software  engineers 
and  managers   to  communicate  through   the   use  of   common    terms. 

But    another    attempt    to    standardize    not    just    terminology    but    practices 
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across    the    firm,     called    "STEP"     (Structured    Techniques    of    Engineering 
Projects),   met  with  much   less  success.      STEP's  objectives  were  much   bolder: 


1.  Enforce  a  set  of  standards  throughout  program 
development 

2.  Provide  an  integrated  tool  set  built  around  a 
portable  data  management  system  for 
configuration  management 

3.  Ensure  that  documentation  was  current 

4.  Provide  relatively  easy  transportation  across 
operating  systems 

5.  Provide  management  reports  on  project  status 


Griffin  explained  STEP's  failure  to  gain  widespread  acceptance  within 
GTE  as  the  result  of  several  factors:  the  decentralized  nature  of  GTE's 
software  development  activities  and  groups;  the  preference  of  software 
engineers  for  familiar  tools;  performance  problems  users  encountered  with 
STEP,  in  comparison  to  tools  integrated  with  the  data  management  services 
of  a  specific  operating  system;  STEP's  narrow  interpretation  of  the  software 
development  methodology;  the  slow  transfer  of  technology  from  the  research 
phase  to  its  use  in  systems  development;  and  the  different  perceptions  among 
GTE  business   units  as  to  what  their   real   economic   needs  were. 

GTE  managers  continued  to  debate  whether  they  should  have  a 
centralized  group  to  develop  software  tools  and  define  methods,  although,  as 
Boehm  would  recommend,  the  company  was  apparently  committed  to  heavy, 
long-term  investment  in  R&D  to  improve  software  quality  and  development 
productivity.        Griffin    expected    high-performance    personal    workstations    to 
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provide  the  bulk  of  GTE's  future  improvements  in  software  development, 
although  he  also  believed  decentralized  or  distributed  environments  would 
greatly  complicate  configuration  management  for  large-scale  product 
development.  Workbenches  were  also  central  to  the  factory  strategies  at 
Toshiba  and  Hitachi,  although  decentralization  of  development  efforts  was 
not.  The  four  dominant  software  engineering  themes  in  GTE  laboratories,  on 
the  other  hand,  were  fully  consistent  with  the  type  of  objectives  sought  by 
Japanese  firms  leading  in  the  factory  model,  including  NEC,  Toshiba,  and 
Hitachi:  specification  accuracy,  integrated  environments,  reusable  software 
components,  and  the  application  of  knowledge-based  systems  to  the  software 
development  process. 

These  efforts,  including  the  factory  efforts  at  SDC  and  in  Japan,  seem 
to  have  provided  firms  with  significant  benefits  even  if  the  programs  did  not 
meet  all  their  goals.  This  was  due  at  least  in  part  to  an  emphasis  on 
improving  conceptual  integration  within  the  design  process,  developing  and 
using  tools  to  support  this,  and  improving  communication  among  development 
groups,  technical  personnel,  and  management.  More  recent  efforts  to 
improve  software  development  productivity  have  focused  on  automation  and 
achieved   greater   success   than    SDC   did. 

The  terminology  used  today  for  automating  system  design  is  computer- 
aided  software  engineering  (CASE).  Such  tools  were  integral  parts  of  the 
software  factories  and  development  efforts  at  NEC,  Toshiba,  Hitachi,  and 
Fujitsu,  as  well  as  at  other  software  producers  in  Japan  and  the  U.S. 
Notable    among     design-automation     tools     sold    by     U.S.     vendors    were    those 
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developed  by  Index  Technology,  Nastec,  KnowledgeWare,  Cadre,  Texas 
Instruments,  Cortex,  and  Tarkenton  Software.  A  Texas  Instruments's  product 
was  one  of  the  first  to  tackle  the  entire  systems  development  life  cycle, 
including  business  objective  analysis  and  data  base  generation.  Other  tools 
which  automate  the  coding  process,  called  application  or  program  generators, 
were  also  central  to  Japanese  facilities  as  well  as  growing  in  popularity 
among  U.S.  tool  developers  and  users.  Cortex,  for  example,  has  developed  a 
system  called  the  Application  Factory  for  the  Digital  Equipment  Corporation 
VAX  market  that  resembled  a  miniature,  flexible  and  automated  factory. ^^ 
This  product,  which  closely  resembled  systems  used  internally  and  marketed 
by  Hitachi  and  NEC,  automatically  generated  software  from  specifications  set 
by  computer  professionals,  and  at  Du  Pont  Company,  actually  wrote  about 
70%  of  the  code  for  a  particular  project,  contributing  to  a  cost  savings  of 
about  82%. 32 

In  addition  to  CASE  products  available  for  sale  are  those  U.S.  firms 
have  made  primarily  for  in-house  use.  TRW  designed  ARGUS,  for  example, 
as  an  advanced  software  engineering  workbench  and  integrated  approach  to 
improve  quality  while  reducing  the  cost  of  software  development.^"^  AIDES 
is  the  Automated  Interactive  Design  and  Evaluation  System  developed  and 
used  at  the  Hughes  Aircraft  Company,  designed  to  automate  many  of  the 
manual  procedures  accompanying  a  structured  design  methodology  developed 
at  IBM.'^''  The  next  step  in  automation  many  firms  are  taking  is  to  link  a 
CASE  tool  to  an  application  generator.  U.S.  products  of  this  type  include 
Cortex's  CorVision,  designed  to  be  a  well -integrated  version  of  the 
product. ^^      Texas    Instruments    is    said    to    have    developed    a    product   which 
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"thoroughly  automates  every  process  even  vaguely  associated  with  software 
development,"  although  this  is  also  described  as  exceedingly  unwieldy.  ° 
Other  U.S.  vendors,  as  well  as  Japanese  firms,  were  focusing  on 
incorporating  expert  systems  technology  into  their  products.  KnowledgeWare 
Inc.  and  Tarkenton  Software,  for  example,  have  combined  their  efforts  to 
make  a  workbench  for  systems  analysts  that  will  automate  everything  from 
the  early  design  work  to  the  generation   of  computer  code.^' 
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CONCLUSIONS 

The  SDC  experiment  was  clearly  part  of  a  large  and  ongoing  effort  in 
the  U.S.,  Japan,  and  elsewhere  since  the  1960s,  to  develop  methods,  tools, 
and  entire  enviroments  to  improve  software-engineering  productivity,  product 
quality,  and  management  control.  One  reason  the  factory  did  not  perform 
well  was  the  variety  in  SDC's  product  lines  and  management  failure  or 
inability  to  manage  the  work  flow  to  suit  the  facility.  This  need  to 
"decentralize"  development  efforts  can  also  be  seen  in  GTE  and  numerous 
other  firms,  and  runs  counter  to  the  centralization  tendency  implicit  in  the 
factory  ideal.  This  suggests  that  factory  models  may  be  appropriate  only  for 
developing  certain  types  of  software  in  firms  willing  to  accept  a  certain 
amount  of  centralization,   discipline,    and  product/market  focus. 

On  the  other  hand,  the  primary  goal  of  SDC  was  not  to  mimic  all  the 
factory  aspects  of  hardware  production,  but  rather  to  apply  a  consistent, 
disciplined,  and  repeatable  approach  to  the  software  development  process, 
capturing  some  of  the  efficiencies  of  production  found  in  a  manufacturing 
environment.  Hence,  SDC  did  not  completely  "fail"  in  its  attempt  to 
automate  and  standardize  the  software  development  process.  It  anticipated 
many  developments  that  followed  and  its  performance  in  the  overall  survey 
criteria  was  above  average  and  among  the  leaders  for  U.S.  firms.  Yet,  by 
not  pursuing  the  factory  model  further,  SDC  may  have  needlessly  abandoned 
some  important  objectives  and  possibilities  for  managing  software  engineering 
more  strategically  and  efficiently. 
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Sustaining  Committment  to  an   Innovation 

At  SDC,  the  introduction  of  the  Software  Factory  disrupted  an 
established  methodology  for  developing  software  systems.  If  the  established 
procedures  were  totally  adequate,  SDC  would  not  have  identified  so  many 
problem  areas  and  attempted  such  a  grand  experiement.  On  the  other  hand, 
the  disruption  and  unsuitabiity  of  certain  aspects  of  the  Factory  made  it 
difficult  to  sustain  the  innovation  attempt.  Management  of  the  change  to 
encourage  acceptance  and  to  ensure  rapid  absorption  of  new  procedures  and 
technologies  always  requires  careful  supervision  and  skill,  as  well  as  time 
and  planning.  While  programmer  resistance  may  or  may  not  have  been  a 
problem,  except  for  a  reluctance  to  use  the  program  library  that  persisted 
into  the  1980s,  the  variety  of  the  company's  work  flow  and  managers' 
reluctance  to  give  up  control  of  product  development  seemed  to  hinder 
effective  implementation  of  the  concept,    dooming  the  experiment. 

The  end  of  the  experiment  was  apparently  followed  by  a  deemphasis  on 
investment  in  process  technology.  Tool  development  needs  to  be  a  continous 
activity;  software  engineering  has  advanced  sufficiently  that  new  tools 
become  available  frequently  and  render  many  existing  ones  obsolete  quickly. 
SDC,  in  fact,  has  replaced  the  tools  of  the  Software  Factory  far  faster  than 
it  has  replaced  the  Factory  procedures.  But  SDC  allowed  much  of  the 
Factory  as  originally  designed  to  become  obsolete;  the  Factory  was  also 
supposed  to  accommodate  new  tools  as  they  became  available,  but  at  least 
one  key  manager  admitted  that  tool  development  fell  behind  other  firms.  In 
contrast,  the  development  systems  at  Toshiba,  Hitachi,  and  NEC  have  been 
continually    evolving,     both     in     terms    of     policies     and     technology,     following 
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long-term  plans  and  sustained   Investment.    ° 


Th  work  flow  problem  was  symptomatic  of  SDC's  varied  contract 
business  at  Santa  Monica,  as  well  as  of  the  nature  of  the  products  it  was 
developing.  The  product  technology  was  not  particularly  stable  and  thus 
suitable  for  a  "mass-production"  atmosphere.  But  other  companies  such  as 
NEC,  Toshiba,  and  TRW,  also  with  varied  product  portfolios,  have  managed 
to  discipline  their  development  efforts  much  more  successfully.  The  Factory 
technologies  and  policies  thus  were  not  necessarily  inappropriate  to  the 
product/market  requirements  of  SDC,  although  SDC's  customer  base  seems  to 
have  made  successful   process   innovation  more  difficult. 


Managing  People  as  well  as  Technolociv 

The  lack  of  a  consistent,  similar  flow  of  work  through  the  Factory 
meant  SDC  managers  could  not  justify  the  Factory's  continued  existence  and 
development.  Better  production  planning  along  with  more  management 
commitment  to  maintaining  the  Factory  intact  might  have  prevented  the 
failure.  But  a  basic  problems  seems  to  be  that  SDC's  implementation  effort 
asked  for  organizational  and  process  innovation  but  did  not  provide 
sufficient  socializing  of  the  people  involved.  Making  "the  factory  workers 
go  to  the  work"  rather  than  having  the  work  flow  through  the  factory  was 
an  organizational  adaptation  to  an  operational  situation  that  appears  to  have 
worked,  but  it  also  undermined  much  of  the  initial  innovation's  potential. 
Numerous  Japanese  firms  and  two  U.S.  firms  or  facilities,  as  indicated  in  the 
survey,     are    significantly    ahead    of    SDC    in    implementing    factory-type    tools 
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and  policies. 

Whereas  it  is  appropriate  to  distinguish  between  a  technological  and  a 
management-policy  infrastructure  in  large  scale  software  development 
organizations,  it  is  also  possible  to  differentiate  further.  There  are  (1) 
formal,  standardized,  proceduralized,  and  automatable  management  practices 
or  constructs  in  the  management-policy  infrastructure;  and  (2)  those  areas  of 
managing  people  which  do  not  lend  themselves  so  well  to  computerized 
automation,  but  require  personal  interaction  and  consideration.  With  regard 
to  this  distinction,  SDC's  way  of  building  a  software  factory  was  quite 
different  from  the  approaches  followed  at  NEC,    Toshiba,    and   Hitachi. 

For  example,  Hitachi,  which  launched  the  world's  first  software  factory 
effort  in  1969,  took  nearly  a  decade  to  institute  standards  and  collect  data 
on  project  management,  productivity,  and  quality  (defects)  before  investing 
heavily     in    technology    and    automated    tools.  In    contrast,     SDC    tried    to 

impose  a  sophisticated  technological  infrastructure  and  a  disciplined  policy 
infrastructure  at  once,  and  with  inadequate  planning  or  analysis  of  its 
product   portfolio  and   production   operations. 

In  examining  articles  and  practices  of  several  different  Japanese 
software  firms,  this  type  of  contrast  becomes  even  more  explicit.  Although 
additional  case  studies  are  needed,  key  elements  in  the  success  of  Toshiba's 
Software  Factory  appear  to  be  compulsory  education  for  all  employees  in  the 
factory  methods  and  tools,  standardization  of  software  development  and 
quality    practices,    and    a    concentration    on     "how   to   control    software   people    so 
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as  to  observe,  and  follow  the  plans  without  losing  their  morale  [sic]."^^ 
Fujitsu  expects  its  programmers  and  customers  to  understand  fully  its 
"Software  Development  Engineering  Methodology"  standards,  and  the  company 
has  continuously  conducted  educational  campaigns  and  seminars  for  project 
leaders  and  administrators  since  1977.  Development  is  also  seen  as 
continuous.  With  regard  to  another  tool,  the  "Software  Development 
Support  System,"  a  Fujitsu  engineer  states  that,  "...  there  is  an  increasing 
number  of  projects  applying  SDSS  and  we  are  planning  to  improve  it  further 
in  the  light  of  problems  and  various  needs  which  may  arise  during  its 
present  application."^^ 

The  founder  of  Toshiba's  Software  Factory,  Matsumoto  Yoshihiro,  writes 
in  another  article,  "...human  factors  in  software  management  are  becoming 
increasingly  important;  therefore  human-oriented  reviews  and  inspections  are 
being  applied  to  increase  software  reliability."^^  Tajima  and  Matsubara, 
software  managers  formerly  at  Hitachi  and  now  at  a  subsidiary,  Hitachi 
Software  Engineering  (HSE),  assert  as  well  that  the  software  industry 
depends  largely  upon  individuals:  "Realizing  the  critical  role  that  people 
play  in  the  company's  success,  HSE  makes  a  major  educational  investment  in 
its  employees--an  investment  that  pays  off  in  employee  loyalty."^  In  this 
same  vein  is  an  observation  by  Mizuno  Yukio,  a  vice-president  and  head  of 
NEC's  software  effort: 


...the  only  difference  is  the  human  element"  [referring  to  software 
quality  differences  between  Japanese  and  U.  S.  companies]  ... 
Teamwork  is  the  key  .  .  .  the  human  factor  must  receive  adequate 
consideration  ...  People  are  at  the  heart  of  software  work.  Here, 
teamwork  will  be  the  key.  Team  members  working  together  are, 
in    their    collective    wisdom,     far    more    effective    than     individuals 
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working  alone.  .  .  .  group  activity  motivates  the  individual  and  the 
team  ...  There  are  three  psychological  keys  to  motivation.  First 
the  worker  should  know  the  significance  of  what  he  works  on;  he 
must  by  himself,  recognize  his  responsibility  in  his  environment. 
Second,  he  needs  to  be  exposed  to  the  actual  results  of  his 
work.  ..  [third] ,    he   knows  the  team  goal.'^ 


In  each  of  these  examples,  Japanese  managers  engaged  in  software 
process  development  seem  acutely  aware  of  the  human  factors  of  personal 
interaction  --  encouragement,  team-building,  instillment  of  purpose  and 
vision,  expression  of  common  goals.  The  management-policy  infrastructure 
described  in  this  paper  may  not  separate  and  capture  these  non-automatable 
aspects  of  the  management  function.  In  SDC's  Software  Factory  as  well, 
managers  seem  to  have  had  difficulty  understanding  the  goals  and  benefits, 
while  programmers  were  not  told  of  the  significance  of  what  management 
was  trying  to  accomplish.  This  approach  ignored  the  need  to  manage  people 
as   well   as   technology. 

Not  only  did  SDC  programmers  never  became  accustomed  to  using  a 
central  program  library  for  reusability.  The  Software  Factory  met  with 
resistance  from  managers  who  did  not  accept  the  new  system.  Thus,  SDC 
was  left  trying  to  enforce  factory  management  using  computerized  tools 
rather  than  adequately  applying  the  non-automatable  aspects  of  management 
which  address  issues  such  as  personality  and  "turfdom."  The  lack  of 
acceptance  and  enthusiasm  about  the  Software  Factory  by  both  workers  and 
managers  contributed  to  the  disruption  of  what  could  have  been  an  orderly 
evolution--and  not  a  revolution  --  to  a  more  strategic  and  efficient  way  of 
managing  the  process  of  software  development. 
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APPENDIX 

SURVEY  RESULTS:  DATA  SUMMARY  TABLE 

I  =  Technological   Infrastructure  (32=100%) 

II  =   Policy/Methodology   Infrastructure  (60=100%) 

III  =  Total   Factory  Model  (92=100%) 

@  Indicates  two  responses  and  averaged  or  joint  responses. 


COMPANY/FACI LITY 

*NEC@ 

*Toshiba  Software  Factory 

*NEC   Information   Service 

*NT&T  Comm.    &   Info.    Proc.    Lab.@ 

♦Hitachi  Omori  Works 

♦Fujitsu   Info.    Proc.    Sys.    Lab.@ 

♦Nippon   Systemware 

♦Nippon   Business  Consultant 

♦Hitachi   Software  Engineering^ 

♦Nippon   Electronics   Development 

TRW 

Unisys/Sperry@ 

Unisys/SDC 

Control   Data© 

Martin  Marietta/Maryland 

Hughes  Aircraft 

Boeing  Aerospace© 

AT&T   Bell   Labs 

Cullinet 

Martin  Marietta/Denver 

Electronic  Data   Systems© 

Honeywell/Defense  Systems© 

Draper  Laboratories© 

Computervision© 

Applications  Means 

Japanese   (♦) 
U.S. 


1 

89% 

11 

89% 

III 

89% 

84 

87 

86 

81 

88 

86 

81 

77 

78 

78 

73 

75 

77 

73 

75 

72 

70 

71 

56 

67 

63 

53 

50 

51 

41 

48 

46 

97 

83 

88 

91 

72 

78 

72 

77 

75 

84 

67 

73 

59 

76 

70 

83 

63 

70 

84 

53 

64 

72 

58 

63 

64 

59 

61 

69 

43 

52 

61 

43 

49 

44 

42 

42 

34 

17 

23 

28 

25 

26 

69 

62 

65 

71 

72 

72 

67 

55 

60 
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♦NEC/Switching   Systems 

*NEC/Operating   Systems 

♦Toshiba   Software   Factory 

*NEC   Software 

♦Hitachi    Software  Works(a 

♦Fujitsu    Numazu    Factoryta 

*NT&T   Comm.    C    Info.    Proc.    Lab.@ 

Control    Data@ 

IBM   Endicott 

Data   General  Westboro   &   N.C. 

Boeing   Aerospace^ 

Unisys/Sperry@ 

IBM   Raleigh 

DEC    (VMS) 

Systems  Means 

Japanese    (*) 
U.S. 

OVERALL  MEANS 

JAPANESE  (*) 
U.S. 


98% 

99% 

99% 

92 

92 

92 

84 

87 

86 

84 

87 

86 

78 

70 

73 

77 

68 

71 

58 

48 

51 

78 

67 

71 

78 

62 

67 

61 

63 

62 

77 

53 

61 

61 

62 

61 

84 

43 

58 

41 

48 

46 

75 

68 

70 

82 

78 

80 

69 

57 

61 

71 

64 

67 

76 

75 

75 

68 

56 

60 

Statistical  Analysis  of  Sample: 


Variable: 

Sample  Size: 

Average: 

Median 

Mode 

Standard   Deviation: 

Range 

Kurtosis: 

Standardized   Kurtosis; 


Totals 

Technology 

Policy 

38 

38 

38 

66.89 

71.18 

64.45 

70 

77 

67 

86 

84 

43 

17.26 

17.40 

18.59 

76 

70 

82 

0.31 

0.03 

0.02 

0.40 

0.03 

0.03 

58 


RANKINGS:   TECHNOLOGY/FACILITY  INFRASTRUCTURE 

8  Questions;   32=100% 

Key: 

A.J.   =  Applications  Japan 
A.U.   =  Applications  U.S. 
S.J.   =  Systems  Japan 
S.U.    =  Systems   U.S. 
*         =  Japanese  firms 


COMPANY/FACILITY 

% 

S.J 

*NEC/Switching   Systems 

98 

Flexible 

A.U. 

TRW 

97 

Factory 

S.J. 

*NEC/Operating  Systems 

92 

Approach 

A.U. 

Unisys/Sperry 

91 

A.J. 

*NEC 

89 

A.J. 

♦Toshiba  Software  Factory 

84 

S.J. 

♦Toshiba  Software  Factory 

84 

A.U. 

Boeing  Aerospace 

84 

S.U. 

IBM  Raleigh 

84 

S.J. 

*NEC  Software 

84 

A.U. 

Hughes  Aircraft 

83 

A.J. 

*NEC   Information   Service 

81 

A.J. 

*NT&T  Comm.    &   Info.    Proc.    Lab. 

81 

A.J. 

♦Hitachi  Omori  Works 

78 

S.U. 

IBM  Endicott 

78 

A.U. 

Control   Data 

78 

A.J. 

♦Fujitsu   Info.    Proc.    Sys.    Lab 

77 

S.U. 

Control   Data 

77 

S.J. 

♦Hitachi   Software  Works 

78 

S.J. 

♦Fujitsu   Numazu   Factory 

77 

S.U. 

Boeing  Aerospace 

77 

A.J. 

♦Nippon   Systemware 

72 

A.U. 

AT&T   Bell   Labs 

72 

A.U. 

Unisys/SDC 

72 

A.U. 

Martin  Marietta/Denver 

69 

A.U. 

Cullinet 

64 

S.U. 

Data  General  Westboro   &  N.C. 

61 

A.U. 

Electronic  Data   Systems 

61 

S.U. 

Unisys/Sperry 

61 

A.U. 

Martin  Marietta/Maryland 

59 

S.J. 

♦NT&T  Comm.    &   Info.    Proc.    Lab. 

58 

A.J. 

♦Nippon   Business  Consultant 

56 

A.J. 

♦Hitachi   Software  Engineering 

53 

A.U. 

Honeywell/Defense  Systems 

44 

S.U. 

DEC   (VMS) 

41 

A.J 

♦Nippon   Electronics   Development 

41 

A.U. 

Draper   Laboratories 

34 

A.U. 

Computervision 

28 

Job  Shop 

59 


RANKINGS:    POLICY/METHODOLOGY    INFRASTRUCTURE 


15  Questions,    60=100% 

COMPANY/FACILITY 

S.J. 

S.J. 

A.J. 

A.J. 

A.J. 

S.J. 

S.J. 

A.U. 

A.U. 

A.J. 

A.U. 

A.J. 

A.J. 

A.U. 

S.J. 

A.J. 

S.J. 

A.J. 


*NEC/Switching  Systems 
*NEC/Operating  Systems 
*NEC 

*NEC    Information    Service 
♦Toshiba   Software   Factory 
♦Toshiba   Software   Factory 
*NEC   Software 
TRW 

Unisys/SDC 

*NT&T   Comm.    &    Info.    Proc.    Lab. 
Martin   Marietta/Maryland 
♦Fujitsu    Info.    Proc.    Sys.    Lab. 
♦Hitachi   Omori  Works 
Unisys/Sperry 
♦Hitachi   Software  Works 
♦Nippon    Systemware 
♦Fujitsu    Numazu    Factory 
♦Nippon    Business   Consultant 

A.U.         Control    Data 

S.U.         Control   Data 

S.U.         Data   General  Westboro   &   N.C. 

A.U.         Hughes   Aircraft 

S.U.         IBM   Endicott 

S.U.         Unisys/Sperry 

A.U.        Cullinet 

A.U.        AT&T   Bell    Labs 

S.U.         Boeing   Aerospace 

A.U.         Boeing   Aerospace 

A.J.        ♦Hitachi   Software   Engineering 

S.J.        ♦NT&T   Comm.    &   Info.    Proc.    Lab. 

S.U.         DEC    (VMS) 

A.J  ♦Nippon   Electronics   Development 

S.U.         IBM   Raleigh 

A.U.         Martin   Marietta/Denver 

A.U.         Electronic   Data   Systems 

A.U.         Honeywell/Defense   Systems 

A.U.         Computervision 

A.U.         Draper   Laboratories 


% 

99 

Flexible 

90 

Factory 

89 

Approach 

88 

87 

87 

87 

83 

77 

77 

76 

73 

73 

72 

70 

70 

68 

67 

67 

67 

63 

63 

62 

62 

59 

58 

53 

53 

50 

48 

48 

48 

43 

43 

43 

42 

25 

17 

Job  Shop 

60 


RANKINGS:  TOTAL  FACTORY  MODEL 


23  Questions,   92=100% 

COMPANY/FACILITY 

% 

S.J. 

♦NEC/Switching  Systems 

99 

Flexible 

S.J. 

*NEC/Operating  Systems 

91 

Factory 

A.J. 

*NEC 

89 

Approach 

A.U. 

TRW 

88 

A.J. 

*NEC   Information  Service 

86 

A.J. 

♦Toshiba  Software  Factory 

86 

S.J. 

♦Toshiba  Software  Factory 

86 

S.J. 

*NEC  Software 

86 

A.J. 

*NT&T  Comm.    &   Info.    Proc.    Lab. 

78 

A.U. 

Unisys/Sperry 

78 

A.U. 

Unisys/SDC 

75 

A.J. 

♦Hitachi  Omori  Works 

75 

A.J. 

♦Fujitsu   Info.    Proc.    Sys.    Lab. 

75 

S.J. 

♦Hitachi   Software  Works 

73 

A.U. 

Control   Data 

71 

S.J. 

♦Fujitsu   Numazu   Factory 

71 

A.J. 

♦Nippon  Systemware 

71 

A.U. 

Martin  Marietta/Maryland 

70 

S.U. 

Control   Data 

70 

A.U. 

Hughes  Aircraft 

70 

S.U. 

IBM  Endicott 

67 

A.U. 

Boeing  Aerospace 

64 

A.J. 

♦Nippon   Business  Consultant 

63 

A.U. 

AT&T   Bell   Labs 

63 

S.U. 

Data  General  Westboro  &  N.C. 

62 

S.U. 

Boeing  Aerospace 

61 

A.U. 

Cullinet 

61 

S.U. 

Unisys/Sperry 

61 

S.U. 

IBM  Raleigh 

58 

A.U. 

Martin  Marietta/Denver 

52 

S.J. 

♦NT&T  Comm.    &   Info.    Proc.    Lab. 

51 

A.J. 

♦Hitachi   Software  Engineering 

51 

A.U. 

Electronic  Data  Systems 

49 

S.U. 

DEC   (VMS) 

46 

A.J 

♦Nippon.  Electronics   Development 

46 

A.U. 

Honeywell/Defense  Systems 

42 

A.U. 

Computervision 

26 

A.U. 

Draper  Laboratories 

23 

Job  Shop 
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